Let me rant an explanation to the situation with Apple, Trim, and 3rd party drives:
First at the level of what hackintoshers are seeing with their systems, Trim doesn't "organize" anything. To understand why you are running into these boot delays requires a survey of storage history, s study of specific drive features and behaviors beyond what any user is willing to investigate, and access to the OS source code.
A 20,000 ft survey is as follows:
Trim command is a hack invented by Microsoft to get the OS involved in SSD mgmt in early days of flash drives. This hack made it into SCSI as well as ATA.
The reason the hack came about was an essential problem with flash memory that it can be written a block (eg LBA of 512 or 4,096 bytes) at a time, but once a block has been written, it can't be re-written until the much-larger flash page in which it resides is reset, where a page is more like 16K. Flash pages can only be reset about 1000 times before they become unstable. Hence the need for "wear leveling". This implies the drive has some internal system for managing wear, and the fact that small writes can lead to reset of much larger flash pages produces a concern about "write amplification". Naturally the storage user is concerned about how much he can use a device with a clear ceiling on writes, and workloads where writing 1 block causes 10 blocks of wear seem like a concern. In early days, Microsoft thought it could help by having the OS tell the drive when blocks are free so it could refresh them without copying their contents, thereby obviating the amplification. There was a certain logic to this at time flash drives were invented: the controllers were simple and an OS dependency is something MSFT would never say no to. So they helped spec the ATA DISCARD command (in SCSI a similar function was known as UNMAP), which later became "Trim" and tasked the filesystem driver with sending Trim commands to let drives know what blocks can be reset without copying their contents elsewhere in flash.
"Sounds groovy, baby"
The expectation was that if the drive can use this information to free flash pages without copying data it will. the early flash storage industry didn't have a the knowhow nor a story about the implications so the idea got standardized.
lBut the idea was not as helpful as MSFT thought. In the simplest sense, the OS sends a list of free blocks via Trim whenever it wants to, including not-at-all, and the drive can do anything it wants with the Trim commands, including nothing — but the existence of the command gives rise to certain semantics regarding reads and previously written data. I don't want to get into this detail, but It's less obvious than you might think. There are spec implications that trimmed blocks should have a specific contents once managed, but the spec is inert on how this should be achieved or what it means to the intervals of the drive.
But it gets worse regarding the determinism of sequences of commands including Trim, and addition of command queueing which ATA didn't support when flash drives first came out. (SATA evolved from PATA which didn't support queuing because the whole interface was a cheapened and dumbed-down SCSI intended for cheap commodities PCs. Eventually SATA reclaimed certain SCSI functionality in the form of server SAS and then Intel did a massive rewrite of the whole storage module with NVMe).
So given the evolving vagueness of specs, the problems of determinism in asynchronous storage I/O in the face of Trim effects and that Trim doesn't have to be supported, what should the drive do in general? For example, if Trim is supported by doesn't include the option for zeroed content (should it ever be zero or what?) should TRIM commands be processed right away or cam they just be noted and processed later? Etc. What does the OS do? It's a hellish situation for any expectations. The semantics can never be fully resolved, because Trim is a mess;
If you think about it, ATA TRIM (UNMAP/DISCARD) is a form of write. Well, write is also a form of discard. So it comes down to whether doing writes at time of file deletion really helps? In some workloads it really doesn't! And a whole swath of edge cases attend the matter. At the simplest level, assuming the Trim commands have to be processed, they can compete with other IO! Is that good? But there are further complexities just owing to the incompleteness of the ATA spec re OS I/O semantics.
In the history of Trim support, one common way to handle this mess is to save Trim accounting for specific times. Apple schedules Trim for filesystem checks and at boot. Linux servers tend to run Trim as a cronjob. The point being that Trim is set aside as something annoying that the OS doesn't want to do because it doesn't know what the drive will do, and the drive can't do well if needs to be told be the OS to do it!
Trim gets the OS into the pants of storage, while storage afraid of being raped. It's a screwed up design that no chance of becoming sexy except as technoweenie fantasy.
THERE'S A SOLUTION TO BAD DESIGN...
Once you realize that Trim is a form of write, you should notice that the drive already gets the news from the OS that blocks (therefore pages) are freed when the OS tells it to write!
With advanced cheap controllers possible in 2020 the drive can run its own mapping system similar to over-provisioning, where it does mapping from a pool of fresh flash for writes and notes that blocks written are resettable, in the same way that virtual memory keeps track of active RAM with a page table and some memory mgmt code. The controller just needs a tiny OS, which is eminently practical these days.
SUMMARY
The drive has to keep track of its flash memory on its own regardless of OS.
The drive maker needs to solve the problem of wear-leveling regardless of Trim.
The storage industry has not developed a consensus on Trim functionality and when they do it will considered a security feature not a performance feature.
NVMe design is more advanced than SATA, which advanced over PATA, which copied a lot from and reduced SCSI. Intel is a key input to these designs because it owns the PC definition. Trim is baked into this evolution like cinnamon; it's everywhere for good or ill.
Apple was not PC architecture until 2006 product designs. In 2021 Apple is surpassing and obviating PC. Apple can do what it likes with storage, just like any other part of its systems. So Trim edge case not surprising.
I think it's hilariously ridiculous that in 2010 Mac user groups were crying about Apple not supporting Trim on their 3rd party drives, when Apple was rightly concerned to not enable a feature with serious edge cases. The community cried and Apple supplied the trimforce command even though no one could even figure out if Trim actually did anything and if did, is what it does even good! Now 10 years later another community of Apple ex-pats are upset that they can't get rid of Trim.
You can't make anybody happy!
DEAR MR. HACKINTOSH, DON'T BE SURPRISED TO FIND GROWING NUMBERS OF SYSTEMS EDGE CASES WITH YOUR KIT
We're lucky we can even identify the problem as a boot hang. Imagine if the hang was in ongoing I/O? Or if it was just throwing away your data?
I encourage everyone to search for "first ATA spec to include trim command" and notice how you won't get an answer to this question, but you will see a history of discussions about the Trim feature with many exhibits of how no one understands it.
If you really look, you can find academic papers which discuss some positive effects of wear management in very narrow application contexts, but it's a stretch to show how these are meaningful to desktop users. I've kept an eye on this for years and never seen a compelling story on performance, but the hope lives on because everybody keeps talking about how great it is.
I imagine that Apple specs certain Trim semantics for its drives, but we will never be privy to these details. As Apple has moved towards soldering storage into the product, and external storage usually doesn't support Trim, the matter is academic.
Below is some light reading.
Here's a presentation with some background on the commands.
Improving Block Discard Support throughout the Linux Storage Stack, by Christoph Hellwig
https://events.static.linuxfound.org/sites/events/files/slides/discard_0.pdf#page104
Here's the
ATA Command Set Spec as of 2013, just to show how mind-numbing the details can be.
See section 7.5.3.x "Data Set Management" (pg 104 of pdf, 81 of doc)
https://read.seas.harvard.edu/cs161/2019/pdf/ata-atapi-8.pdf#page104
After you read the ATA spec, please tell the class what Trim does, why it is good, and exactly what your choice of drive actually does.
Spoiler: You'll need to read the OS source code!
