This still fascinates me ...
If this is correct - and I have no knowledge to the contrary - then all macOSs back to High Sierra should be affected by the 'bug' because that is when APFS was introduced. As it is today, the problem only seems to be affecting Monterey.
Also firmware Trim should be OS agnostic.
I would like to know more about this issue. It seems to me Monterey must have some new code which is conflicting somewhere, maybe security etc.
If Trim delays were moved from startup to shutdown, would it be more or less annoying.
The application of Trim is OS specific. It's a common approach on Linux servers to not allow Trim on unlink (delete) and run a Trim pass via cron at scheduled times. Trim is a form of write which has -interesting- properties.
It's also architecturally incredibly stupid as it takes internal mgmt details of the storage device and exposes them as a chore for SW at the wrong level of abstraction and where you prefer the OS has no knowledge of the device feature because it should be hidden by a black-box.
The Trim spec as originally conceived is absurdly incomplete and simplistic. Drive makers are free to do anything they want with Trim commands including ignore them, blow up the command queue (which didn't exist in ATA at the time Trim was introduced) or generally bog down I/O. And drive makers are known to just botch Trim.
What needs to be understood about Trim is that it's a Microsoft invention in the worst sense, where some storage ninnies decided to deal with a point-in-time workaround to limited logic in early SSDs by ratifying a standard ATA command to let the OS "help" manage inner workings of a storage device. If you are Microsoft you want your stupid OS in there gumming things up as much as possible because it's a profit center. Here is where we can find a direct analogy to Winmodem, which was Intel's snazzily stupid idea of putting old Hayes-style mod/demod for data over voice lines (remember AOL YOU'VE GOT MAIL) in the CPU because it used an expensive CPU that you can't live without to save a few dollars of system build cost on dedicated mux chips. Another hellish design history that relates to the dungeon of Trim is old CHS block addressing of disks, where the OS driver was expected to know and manage the platter/head geometry of the drive. If you were to suggest today that what storage devices need is CHS addressing to improve this lame LBA setup so the OS can get more involved in sector allocation, well that's how Trim is to SSD garbage collection.
It's a fact of history that Microsoft didn't think through any of the long-term problems with the Trim approach and their general ignorance combined with weak early SSD designs to make customers start to demand the feature, partly because they know even less about viable systems architecture trends than Microsoft — and who doesn't worry a lot about their precious drives getting all used up and everything!
For Mac this hit an apex with 'informed' users griping openly that Apple was short changing them by not enabling "TRIM SUPPORT" on 3rd party drives, when actually Apple was just making sure that 3rd party drives don't throw away your data.
The big picture is that Trim does add some value because history conspired to provide Trim, but history is stupid too.
Here's another way to think about what Trim does that doesnt require a special write command I OFFER THIS FREELY TO THE INDUSTRY: If you allow controller logic to get arbitrarily complex, which it now can be, and you look at the problem Trim is designed to solve which is pre-allocating writes by getting the OS to tell you that it plans to rewrite-some-blocks-in-some-arbitrarily-distant-future-so-why-not-waste-time-now-setting-up-the-flash-pages-for them, you should quickly realize that the OS is already telling the drive what it plans to write in the future by issuing... WRITES! As all drives start empty, incoming normal writes tell the controller everything it needs to know about free flash: if flash pages are under a write request, they're free to be cleaned. So the drive can just note the extents that the OS has requested, map some factory-fresh clean pages to the addresses space that's been requested, and add the pages that were under the write request to the GC queue to clean up when not otherwise busy. All that's needed is something like a flash pagetable that works pretty much like OS virtual memory, with some buffering and vendor juju and secret sauce for market workloads. I bet the controller designers have already figured this out! Or have they?
As to what Trim actually does today, and how the OS interacts with it is all juju with some general trends which allow a carefully crafted storage subsystem with some knowledge of device specific details to overcome some point-in-time workload issues IFF the storage system designer is totally aware of what a specific device does and the specific device actually does what the OS thinks it does... What about this arrangement is not agreeable to a hackintosh style of system build?! Omg so here we are with some edge cases that are making users with zero pull cranky because their cobbled-together systems are hodge-podges of parts that nobody owes architectural fidelity for an application the industry doesn't want! What part of this is mysterious?
Any way, yes please add new entries to the lists of known-to-not-yet-break-and-destroy-all-your-data drives.
Carry on
