TRIM problems in Mojave Beta

[gorila]

On my NUC I have both 10.13 and 10.14 Beta on two separate disks:

1. Mojave Beta 5 on Kingston SH103S3120G
2. High Sierra 10.13.5 on Crucial CT256M550SSD3

Both disks use APFS. My other hardware is presented in my profile.

Clover is on High Sierra disk. Both OSs are sharing exactly the same Clover settings. With such configuration I was able to compare 10.13 and 10.4 on almost consistent basis.

Recently, I have enabled TRIM in Clover Kernel & Kexts Patches, which affects both installs. Both OSes have shown no advantages of the use of TRIM. However, the boot time of Mojave has significantly increased with TRIM enabled.

To investigate this performance detorriation I have removed TRIM Enabler from Clover and have used terminal command ’sudo trimforce enable’ . The result was the same: the boot time of Mojave has significantly increased with TRIM enabled, regardless whether it was enabled from either Clover or terminal. This indicates that Mojave Beta itself causes this boot delay. Furthermore, I wanted to allocate where exactly the delay comes from.

In verbose mode I have learned that the delay originates from spaceman_trim_free_blocks scans lasting total 21.3 seconds.This indicates that there might be a bug in Mojave Beta TRIM code.

I have disabled TRIM as an unnecessary complication, at least on my disks. Well, except the argument that TRIM is allegedly more gentle with disks. But I’m sure they will serve me well before I decide to purchase new disks.

This post isn’t intended as a request for help, just my humble observation.

 

[Pavo]

APFS has its own TRIM and you should not enable External TRIM.

 

[gorila]

APFS has its own TRIM and you should not enable External TRIM.

That's true but it appears, however, that TRIM isn't entirely automatic process. Otherwise, "sudo trimforce enable" would have been a redundant command in APFS based systems. Likewise in Windows, users can forcibly control TRIM with "fsutil behavior set DisableDeleteNotify 0".
What I've found, in my particular case, enabling or disabling TRIM doesn't affect disk performance whatsoever, except during the Mojave Beta boot. It appears that Mojave performs a portion of scheduled disk optimisations during the boot but apparently something went wrong in this Beta release.

 

[gorila]

Conclusion:

I have investigated this problem further and I may now dismiss my hypothesis that there is a bug in Mojave TRIM implementation.

To make this conclusion with confidence I have swapped drives. This time OSes were installed as follows:

1. Mojave Beta 5 on Crucial CT256M550SSD3
2. High Sierra 10.13.5 on Kingston SH103S3120G

This time spaceman_trim_free_blocks scans took:

2.3 seconds on Mojave Beta (Crucial CT256M550SSD3)
20.8 seconds on High Sierra (Kingston SH103S3120G)

These results along with these from post #1 indicate that the boot delay may be attributed exclusively to difference in disk performance during the boot. In this particular case there was no other change in disk performance – the both disks were attaining speeds according to their specifications.

This indicates that toggling TRIM on APFS has impact just on boot times and this depends just on drive specifications.

What I wasn’t able to learn is:
1. what is the real benefit from 'free block scans' and
2. whether enabling TRIM on faster disks has any benefit whatsoever.

The answer to question 2 is probably: no practical benefit whatsoever.