[HOW TO] OpenCore 0.7.8 > 0.7.9 differences

[miliuco]

OpenCore 0.7.9 is out. Thank you OpenCore team!

Main changes

• Kernel >> Quirks >> SetApfsTrimTimeout: on macOS 12.0, it is no longer possible to set trim timeout for APFS filesystems. A new method has been added to disable trim when SetApfsTrimTimeout is set to zero. Default is -1.
• Added auto-detection of macOS Installer volume name for use when .disk_label file cannot be displayed.
• Added script to build qemu recovery images to macrecovery.
• Fixed selecting SecureBootModel on hypervisors (should be x86legacy, otherwise macOS 11 will fail to boot).
• Improvements in OpenLinuxBoot,

config.plist (see Sample.plist file)

• Kernel >> Block >> added Strategy property (String): determines the behaviour of kernel driver blocking. Default is Disabled. Most users have nothing in this section so no change has to be done.
• Misc >> Debug >> added LogModules property (String): filters logging generated by specific modules, both in the log and onscreen. Failsafe *:
  + (Positive filtering): Include selected modules
  - (Negative filtering): Exclude selected modules
  * indicates all modules being logged.

Drivers

• AudioDxe >> added configuration options in UEFI >> Drivers >> Arguments: --restore-nosnoop (Boolean flag, enabled if present), making v0.7.7 fix for Windows sound opt-in.

Tools

• ocvalidate >> fixed max file path length.

Kexts

• AppleALC 1.7.0 (new layouts)
• CpuTscSync 1.0.7 (improvements)
• DebugEnhancer 1.0.6 (cosmetic fixes, improvements for macos 12 and newer)
• FeatureUnlock 1.0.7 (improvements for Universal Control)
• VirtualSMC 1.2.9 (fixes)
• VoodooPS2 2.2.8 (fixes and improvements)
• WhateverGreen 1.5.8 (improvements).

 

[Bustycat]

So this confirms that SetApfsTrimTimeout is now limited to 0 and -1 for macOS 12+.

 

[miliuco]

So this confirms that SetApfsTrimTimeout is now limited to 0 and -1 for macOS 12+.

Not sure. I think SetApfsTrimTimeout keeps the valid values as before but, as I understand, in macOS 12 if set to 0 disables trim.

 

[Bustycat]

Not sure. I think SetApfsTrimTimeout keeps the valid values as before but, as I understand, in macOS 12 if set to 0 disables trim.

It should be the same to -1 unless using 0, if I understand correctly.

 

[miliuco]

It should be the same to -1 unless using 0, if I understand correctly.

What I'm not sure either is this: in Monterey, setting SetApfsTrimTimeout=-1 doesn't act on the trim timeout as before, does it? Then I can have trim enabled with -1 (and it's macOS that adjusts the trim timeout) or trim disabled with 0. It's something that has me confused.

 

[Edhawk]

The OC Changelog.md for 0.7.9 states the following:

- Added new method to disable trim when `SetApfsTrimTimeout` is set to zero​

​

- Fixed `SetApfsTrimTimeout` on macOS 12 (only works when set to zero)​

This is what the OC 0.7.9 Configuration.pdf says about SetApfsTrimTimeout feature.

SetApfsTrimTimeout
Type: plist integer
Failsafe: -1
Requirement: 10.14 (not required for older)
Description: Set trim timeout in microseconds for APFS filesystems on SSDs.​

​

The APFS filesystem is designed in a way that the space controlled via the spaceman structure is either used or free. This may be different in other filesystems where the areas can be marked as used, free, and unmapped. All free space is trimmed (unmapped/deallocated) at macOS startup. The trimming procedure for NVMe drives happens in LBA ranges due to the nature of the DSM command with up to 256 ranges per command. The more fragmented the memory on the drive is, the more commands are necessary to trim all the free space.​

​

Depending on the SSD controller and the level of drive fragmenation, the trim procedure may take a considerable amount of time, causing noticeable boot slowdown. The APFS driver explicitly ignores previously unmapped areas and repeatedly trims them on boot. To mitigate against such boot slowdowns, the macOS driver introduced a timeout (9.999999 seconds) that stops the trim operation when not finished in time.​

​

On several controllers, such as Samsung, where the deallocation process is relatively slow, this timeout can be reached very quickly. Essentially, it means that the level of fragmentation is high, thus macOS will attempt to trim the same lower blocks that have previously been deallocated, but never have enough time to deallocate higher blocks. The outcome is that trimming on such SSDs will be non-functional soon after installation, resulting in additional wear on the flash.​

​

One way to workaround the problem is to increase the timeout to an extremely high value, which at the cost of slow boot times (extra minutes) will ensure that all the blocks are trimmed. Set this option to a high value, such as 4294967295, to ensure that all blocks are trimmed. Alternatively, use over-provisioning, if supported, or create a dedicated unmapped partition where the reserve blocks can be found by the controller. Conversely, the trim operation can be disabled by setting a very low timeout value. e.g. 999. Refer to this article for details.​

On macOS 12+, it is no longer possible to set trim timeout for APFS filesystems. However, trim can be disabled when the timeout value is set to 0.​

​

So as I see things:

• In Mojave, Catalina and Big Sur the SetApfsTrimTimeout should be set as -1 for most system boots.
• But with a long timeout in milliseconds that allows Trim operations to complete on specific boots.
• This I think should be done on a regular timescale, so Trim is enacted on the drive, just not every time the system boots.
• This could and should prevent the wear on the drive as Trim is run to completion on at least a monthly basis, logically when we update OC to the new monthly release.
• In Monterey SetApfsTrimTimeout should be set as 0, to disable trim. As it doesn't work on APFS drives in Monterey.

 

[Edhawk]

Strangely enough my Samsung SM951 NVMe drive takes the same time to boot (Big Sur) whether I have SetApfsTrimTimeout as -1, 0 or 4294967295.

Not sure if this is a sign that Trim is OK on my drive, or not working at all?

 

[miliuco]

@Edhawk
My 2 WD SN750 M2 disks also take the same time to boot Big Sur and Monterey with SetApfsTrimTimeout 0 or -1. I think it says our disks do trim so quickly at boot that trim timeout value doesn’t matter.

 

[Edhawk]

That was is a thought I had too, but I was just surprised when the long timeout was just as quick. I don't know why I just expected it take a bit of time and to be a bit more thorough maybe?

 

[Superbogey]

@miliuco Do you happen to know why there is no 0.7.9 compatible OCAuxiliaryTools release (I just got an update for it but it still says it's for OC 0.7.8)?