MacInTouch Amazon link...

SSD, Fusion and flash drives

Channels
Security, Products

Ric Ford

MacInTouch
But I do have a thumb drive attached to my keychain, give them to friends and families as a way to distribute photos, and use them for keeping my collection of bootable Linux ISOs and macOS installers.
I got a call a while back from a friend. His wife had been keeping files on a thumb drive (photos, I think) with no other backup. She'd been doing this for a long time - on the same thumb drive. The thumb drive had just died... And, no, we couldn't recover any files from it.
 


David, your description of the difference between Trim and "garbage collection" is clear, and one of the best I've read. What isn't clear is what you mean by logical blocks being overwritten triggering garbage collection in the absence of Trim.
It is my understanding that opening a file is just a read operation. But that if the file is edited and saved back to an SSD, the drive controller may write the new save to a different memory location and "know" to mark the prior location for collection. Is that what you mean?
It remains my understanding that, in the absence of Trim, deleting a file in a computer's OS does not mark the file's memory location on an SSD as available to clean. We certainly wouldn't want the SSD controller removing files just because they haven't been (e.g.) accessed in months. I have a couple of Android devices with Google programs that offer to do just that, to improve performance and open space, and it's actually scary.
I think I wrote about this a while ago, but I can't find the link, so I'll try to recall everything.

Any storage device, seen from the outside (e.g. over the SATA interface) consists of a sequence of logical blocks. Each logical block is a fixed size (typically 512 bytes, but some devices may use 4K or 8K logical blocks, in order to align with the flash memory's page size - see below). The storage presents itself as a linear sequence of logical blocks. The logical blocks are numbered, and the number is used to identify the physical location in the storage media where the data resides.

On a hard drive, each logical block directly corresponds to a physical location on a platter (a particular cylinder, head and sector). The mapping may be complicated but is (more or less) fixed. Every time you read/write a given logical block, the drive hardware reads/writes the same physical location. In practice, it's a little more complicated, because drive firmware may relocate a logical block to a new physical location if it thinks the old location has failed or is expected to fail soon, but overall these mappings don't change.

On an SSD, things don't work this way. There is a mapping from logical blocks to physical storage, but that mapping is constantly changing, due to the nature of how flash memory works.

Flash memory is organized in pages and blocks. A page is the smallest unit that you can write to (typically 4K or 8K bytes, but may be as low as 512 bytes). A block is the smallest unit that you can erase and will consist of a lot of pages (typically 32-128 pages plus some housekeeping overhead, yielding a typical block size between 16K and 512K bytes). For the purpose of this post, I'm going to assume a 512 byte logical block, a 4K page and a 512K flash block (128 pages).

In an SSD like this, when you write a 512 byte logical block, the SSD controller must find an unused (4K) page and write that logical block to it. If you're writing multiple logical blocks at once, the controller will probably combine them together (e.g. 8 of them at a time, so it can fill entire pages) in order to be more efficient. If you're not writing data in multiples of the page size, then the controller may find a page with free space (e.g. one where not all of its 8 logical blocks are used) and merge its content with your new logical blocks. But it can't just write your data to a page that already contains data - it must read the whole page into RAM, merge your new data, and then write the merged page back to a different page of flash memory (updating the logical-to-physical mapping tables, so no data is lost). Once this is done, the page that those other logical blocks came from is no longer used by anything - it is garbage and is marked as such, so it can later be erased.

But the controller can't just erase the page; it can only erase whole blocks (128 pages in our example). So it will just keep track of which pages are garbage (and which logical blocks within each page do or do not contain valid data). When an entire block (128 pages) is left with nothing but garbage (or garbage and empty pages), it is safe to erase the block and will eventually do so, making all of its pages available for writing again.

As you can see, every time you write to an SSD, whether you're writing to a new logical block or repeatedly overwriting the same logical block, you are actually writing data to new/different pages in the flash memory, and other pages are marked as garbage. And the controller's mapping from logical block number to physical location in the flash memory changes each time - not just for the logical block you're writing, but for any other logical blocks that share pages with it.

If your usage (and the SSD controller's firmware) is perfect, then this system might be all you need. But in actual practice, you're randomly writing data all the time, so you find lots and lots of blocks of flash memory where there are some blank pages, some in-use pages and some garbage pages. Eventually, you run out of blank pages. Once this happens, the SSD controller needs to erase something, but there are no all-garbage blocks to erase.

This is where garbage collection comes in. The SSD controller needs to rearrange the pages with good data in order to create blocks it can erase.

One (probably naive) algorithm might be for the controller to read all the valid pages (up to 512K bytes) into RAM, erase the flash block, then write the valid pages back, leaving the formerly-garbage pages blank and ready for writing.

A better algorithm might do this in the background when the SSD is idle, in order to avoid making your OS hang (which is what seems to happen if an SSD actually runs out of free pages and is forced to garbage-collect at that point).

Other algorithms may track usage statistics and proactively relocate logical blocks and pages to different locations in a way to maximize the ability to free blocks in the background.

Actual SSDs use pretty complicated algorithms for garbage collection in order to deal with issues of wear leveling and write amplification, both of which can shorten the life of an SSD and degrade performance if they are not dealt with properly.

And now here's where Trim comes in.

Most operating systems do not try to erase logical disk blocks when you delete a file. They just delete directory entries and record that the logical blocks are free. This is a good thing (unless you require secure erasure), because it's a lot faster. But seen from the SSD controller's view, the logical blocks are not free - they're still holding data, and they will continue to hold that data until the logical block is overwritten with new data — which means the flash memory's blocks and pages may contain non-garbage data corresponding to files that have been deleted. We'd like to treat those blocks as garbage, so they can be collected, but we can't, because [the SSD] has no way to know that they correspond to deleted files.

Trim is an API where the operating system can tell the SSD that certain logical blocks no longer contain valid data. Typically, these are blocks corresponding to deleted files, but it could be for any kind of deleted data (like a partition you just deleted or erased). When the OS calls Trim for a logical block, the SSD controller immediately marks the underlying storage (a piece of a page) as garbage. So when garbage collection is performed on that page or block, the controller won't try to preserve that chunk of data. This allows the garbage collection algorithm to erase more blocks and not waste time preserving the content of deleted files.
 


I think I wrote about this a while ago, but I can't find the link, so I'll try to recall everything.
Again, thanks, David — where I get left behind in the forest of blocks, pages, etc. is this, from a 2010 article explaining SSDs that I believe is still applicable:
Enterprise Storage said:
Fixing SSD Performance Degradation, Part 1
Without TRIM, the SSD controller does not know when a page can be erased.
... The only indication that the controller has is when it writes a modified block to a clean block from the block pool. It then knows that the “old” block has pages that can be erased.
I think the latter comment applies to, e.g., editing a file that's already on the SSD that, when saved back to the SSD, is written to a "clean block." That differs from the "delete" function communicated by Trim.

This is now, I think, less important than when Trim was new and Apple didn't provide for its use on third-party SSDs. Still, we have several Mac Minis at work, all booting from external USB 3-connected SSDs, all without the benefit of Trim. And I've started using SATA SSDs with USB-SATA connectors in place of thumb drives, again without the benefit of Trim. Those drives are so cheap, I don't lose any sleep worrying they'll fill and "just stop", as some of the first SSDs available to consumers in 2008 did. 128 GB for $22 is one thing, $595 for 80 GB quite another.
 


If you have Trim enabled, then those files will become garbage (and subject to collection at some point in the future) as soon as you empty the trash.
My 2017 iMac shipped with Mojave 10.14.3. Is Trim enabled by default, or do I have to do something to enable it?
 


My 2017 iMac shipped with Mojave 10.14.3. Is Trim enabled by default, or do I have to do something to enable it?
Everything I’ve read says that Apple always enables Trim on its OEM SSDs, and it has nothing at all to do with what macOS you run. If you have external SSDs or replaced the internal with a 3rd-party SSD, then consult with the manufacturer to see what they recommend.

I recently read that enabling Trim may not be optimal for the long term, but I haven’t been able to locate what I saw. I’ll be back if and when I do.
 


I recently read that enabling Trim may not be optimal for the long term, but I haven’t been able to locate what I saw. I’ll be back if and when I do.
I've read the same thing - that some SSD makers claim that enabling Trim is bad for their device.

This makes no sense to me. Trim is simply an API where the OS tells the SSD controller about logical blocks that are no longer in use. If the SSD controller's design is such that this information isn't helpful, then it is free to ignore the command. If the SSD controller is doing bad things in response to the command, then its firmware has critical bugs that need to be fixed. Telling people that they simply shouldn't use Trim is a weasel response that is trying to blame customers for their own faulty product.
 



... Fill one bay with an SSD and the other with hard disk drive. They'd need to be in a mode where they present as independent disks (may need to avoid enclosures where only one of the bays is bootable when in independent disk mode — that may knock out some of the examples above). Second, there is a command line diskutil APFS subset command, e.g.
disktutil apfs create device /dev/disk4 /dev/disk5 newFusionDisk
which should create a new Fusion disk...
I have an iMac with a fusion drive made up of a 128GB SSD plus a 2TB 7200-RPM hard drive. I suspect that one could replace the standard SATA hard drive with an SSD and improve performance. As others have pointed out, it is far easier and less costly to buy a 2TB Samsung T5 and run it from the USB-C port as the boot drive. I would then use the fusion drive as the backup via Carbon Copy Cloner. The T5 is so small, one can hide it on the iMac stand.
 



I have an iMac with a fusion drive made up of a 128GB SSD plus a 2TB 7200-RPM hard drive. I suspect that one could replace the standard SATA hard drive with an SSD and improve performance. As others have pointed out, it is far easier and less costly to buy a 2TB Samsung T5 and run it from the USB-C port as the boot drive....
Same path for even a hard disk drive-only iMac. The 500GB version of the T5 linked above 'street price' is $89. Apple wants to charge $100 to slide in a measly 32GB (or 64GB) SSD for the base-level Fusion drive. For anyone whose working space is 425GB or less, it is cheaper to buy the external SSD and just boot that way.

The street price for the Samsung EVO 2TB SSD is about the same as the T5. So, if Apple had just used a SATA SSD in the first place, would end up at the same cost for their Fusion setup (even with some margins on top). Apple's PCIe blade SSDs and T2 SSD solutions are faster, but the SATA SSDs are now a more viable solution they are avoiding for entry models. Since the SATA SSDs are capped on bandwidth (simple SATA is probably not moving forward any time in the immediate future), the focus is more on $/GB affordability. The prices for SATA SSDs are around same zone that HDDs were in after the Thai floods (and Apple managed to do entry models in that era just fine at similar price points to now).

For an iMac, Apple wants to charge $600+ for 1TB and $700+ for 2TB versus the less than $300 "street price" for 2TB here. For sub-3TB clone backup drives, yes, an external SSD is probably better than a "build your own" external Fusion drive for a "fast" clone. As long as they are highly active backups (hooking it up on a regular basis). For more archival, offline (powered down) backups, an APFS hard disk drive backup is better, even if slower.

However, for capacities over 3TB, things get more into a grey area. In 2020, that may change with the next round of even more affordable (lower $/GB) SATA SSDs. Apple's Fusion drives stop at 3TB, so not much long-term impact there. For over 3TB capacity drives, though, HFS+ isn't going away any time soon.

The bigger "painted into a corner" problem for Apple is that, if they had cost-effective SSD in products alongside their highly marked-up ones, they'd have deeper comparison issues.
 


An Apple-standard SSD should automatically have Trim enabled. You can confirm this by running the System Information app and look for the information about your SSD. It will say if Trim is enabled or not.
Thanks! It says Trim is supported (TRIM support: yes), but there is no specific language to say whether it is enabled or disabled.

Is Apple... using supported to mean enabled?
 



Same path for even a hard disk drive-only iMac. The 500GB version of the T5 linked above 'street price' is $89. Apple wants to charge $100 to slide in a measly 32GB (or 64GB) SSD for the base-level Fusion drive. For anyone whose working space is 425GB or less, it is cheaper to buy the external SSD and just boot that way....
I know it's a bit costly, relatively so anyway, but what I purchased from OWC is their 1TB Envoy Pro EX Thunderbolt 3 external drive with an M.2 NVMe inside. (Cost is around $280). Throughput, when hung off the back of one of the TB3 ports on my 2017 5k iMac is approx. 2300MB/sec reads and 2470MB/sec writes. The performance when using the drive as the boot drive is phenomenal.
 


Ric, just in case anyone requires it, I have a set of free "TRIM Tools" I crafted using some already-written Terminal commands I found on the Web that I wrapped up in three Automator workflows. Designed for internally installed third-party SSDs, they will turn TRIM on, off, and report the status of TRIM. They, along with a "read me" may be found here.
 


Same path for even a hard disk drive-only iMac. The 500GB version of the T5 linked above 'street price' is $89. Apple wants to charge $100 to slide in a measly 32GB (or 64GB) SSD for the base-level Fusion drive. For anyone whose working space is 425GB or less, it is cheaper to buy the external SSD and just boot that way....
I have a new older OWC Envoy external Thunderbolt 3 SSD that operates somewhere in the 1000-2000 MB/s range and does quite well. Their newer Envoy Pros are even faster, so I cannot see buying anything more than the minimum SSD on a new machine and then using the external Thunderbolt SSD.
 


I've read the same thing - that some SSD makers claim that enabling Trim is bad for their device. This makes no sense to me. Trim is simply an API where the OS tells the SSD controller about logical blocks that are no longer in use.
The API isn't quite that simple. Trim hasn't been monolithic.
Wikipedia said:
Trim (computing)
A drawback of the original ATA TRIM command is that it was defined as a non-queueable command and therefore could not easily be mixed with a normal workload of queued read and write operations. SATA 3.1 introduced a queued TRIM command to remedy this.
There are, at this point, three variations of Trim.
Wikipedia said:
Trim (computing)
There are different types of TRIM defined by SATA Words 69 and 169 returned from an ATA IDENTIFY DEVICE command:
  • Non-deterministic TRIM: Each read command to the Logical block address (LBA) after a TRIM may return different data.
  • Deterministic TRIM (DRAT): All read commands to the LBA after a TRIM shall return the same data, or become determinate.
  • Deterministic Read Zero after TRIM (RZAT): All read commands to the LBA after a TRIM shall return zero.
Casually, lots of folks treat Trim as if it is the last of the three. (Some "Trim working" tests will do a read for zeros after the call to see if it is 'working' - that Trim will relatively quickly scrub the "old" block data out and replace it with zeroes. If there are multiple read/write requests coming in and a minimally capable SSD controller, that means kicking parallel queues out of the "swimming pool" so that it can single-track the work. Note that it is only the LBA that has to be zero, so an advanced controller can just send back zeros if the block mapping is on the "to be garbage-collected" list. The 'old' data would still be in the NAND block, even though the user level would look like zeroes, which is why writing zeroes isn't necessarily a secure way to erase an SSD.)

In the context of wanting maximum performance with a relatively high read/write queue I/O depth, the original 'bad' Trim pragmatically demanded that the depth be pushed down to zero until had finished at least a portion of the Trim 'work' (impact on controller internal state).
If the SSD controller's design is such that this information isn't helpful, then it is free to ignore the command. If the SSD controller is doing bad things in response to the command, then its firmware has critical bugs that need to be fixed.
The problem was that you couldn't completely ignore it. The way the original Trim was formed, file system folks could expect Trim to clean up race conditions for them. Trim was a big serial lock on the SSD. Once folks write code expecting that, you can end up with issues.
Telling people that they simply shouldn't use Trim is a weasel response that is trying to blame customers for their own faulty product.
I don't think there was a vendor who said never use Trim in any context. It may have been SandForce, who said something to the effect of don't use Trim if you want max performance. That was also in the context of other SSD vendors proclaiming that Trim has to be used or else the "sky will fall." That, too, was a limitation of their SSD controllers (bigger locking around Trim was needed, if they did not do something more sophisticated). There were controllers with really bad garbage collectors that basically needed the Trim metadata to do a reasonable job. Trim should be additional, "cherry on top" data for garbage collection... not the whole mechanism.

So part of "bad" versus "good" was really a battle over queued vs non-queued Trim. Once queued Trim arrived, the whole "bad" argument faded.

P.S. I think some of Apple's "our Trim is the only good Trim" notion was grounded in some of these controllers versus the standard quarrels. At this point, the standards have evolved, and the controllers have had multiple iterations on the stable standards, so that position is much weaker now. A new, modern SSD controller and trimforce enable is probably very low risk. But Trim has changed, and if you go back far in time with a relatively older drive that is on very old standards, then it is a higher risk.
 


Ok, so, while we're on the topic, here's a fun question I've never been able to wrap my brain around: How [with volume encryption] does the drive ever know what's free and what isn't [for Trim and garbage collection]? Doesn't every block appear to be in use 100% of the time if it's encrypted at the volume level, or if the drive has ever been full? ...
 


Ric Ford

MacInTouch
Ok, so, while we're on the topic, here's a fun question I've never been able to wrap my brain around: How [with volume encryption] does the drive ever know what's free and what isn't [for Trim and garbage collection]? Doesn't every block appear to be in use 100% of the time if it's encrypted at the volume level, or if the drive has ever been full? ...
As I understand it, volume encryption is at a lower level than file-system operations, such as file deletions and Trim. So, to the file system, nothing changes between FileVault-encrypted and non-encrypted (and T2-encrypted) volumes. Apps and the OS still read, write, delete and trim blocks in all cases. Blocks are encrypted en-route and decrypted on return, invisibly to apps and the file system, which work with the unencrypted data. The SSD controller doesn’t need to know or care what’s in the blocks; they’re just sets of bytes to be stored, retrieved, or erased, each at a particular location, whatever their contents happen to be.*

FileVault 2/CoreStorage is based on logical volume management. See:

(*Some Sandforce controllers have done unique, tricky compression processing, which has special issues. OWC used and evangelized these extensively.)
 


How [with volume encryption] does the drive ever know what's free and what isn't [for Trim and garbage collection]? Doesn't every block appear to be in use 100% of the time if it's encrypted at the volume level, or if the drive has ever been full?
... FileVault 2/CoreStorage is based on logical volume management. See...
It will, of course, depend on how the encryption system is implemented.

If it's implemented like an encrypted disk image (i.e. as one giant file), then Trim probably can't work, because freed blocks will be indistinguishable from in-use blocks, and the ecncrypted logical blocks may not even align with the device's logical blocks (especially if there is also data compression involved).

If, on the other hand, each block is separately encrypted, or if the algorithm makes certain that each encrypted block corresponds to exactly one logical block, then Trim can still be used. (It might sacrifice some amount of privacy, because freed blocks will probably read back as all zeros instead of as random bits, but only the most paranoid people should consider that a significant breach.)
 


Ric Ford

MacInTouch
I don't remember seeing this back in May, but it's worth noting a Mac compatibility issue with the Samsung 970 EVO Plus SSD (which doesn't affect the plain Samsung 960 EVO version).
BartechTV said:
Samsung releases new firmware for 970 EVO Plus that resolves macOS compatibility issues
Samsung today released a new firmware update for the 970 EVO Plus NVMe SSD that resolves compatibility problems when using the drive under macOS.

Previously, while the original 970 EVO worked without issues, the 970 EVO Plus would cause regular kernel panics under macOS, followed immediately by a spontaneous reboot. With the new firmware installed, the 970 EVO Plus works flawlessly under both macOS and Windows, with speeds around the 3000MB/s mark.
 


Reading this article on SSDs, it appears that the move to quad- and quintuple-density SSDs comes with a cost: speed and, potentially, reliability. Bottom line (in my opinion): this rush to increase density will come at a cost that will be when these "cheap" drives start to fail prematurely....
 


Reading this article on SSDs, it appears that the move to quad- and quintuple-density SSDs comes with a cost: speed and, potentially, reliability. Bottom line (in my opinion): this rush to increase density will come at a cost that will be when these "cheap" drives start to fail prematurely....
Thank you, Barry. Yes, besides the higher failure rate, it seems like these PLC SSDs will be running like regular 7200-rpm hard drive read/write speeds. Just hope Apple doesn't consider using them.
 


It will, of course, depend on how the encryption system is implemented.
If it's implemented like an encrypted disk image (i.e. as one giant file), then Trim probably can't work [...] If, on the other hand, each block is separately encrypted, or if the algorithm makes certain that each encrypted block corresponds to exactly one logical block, then Trim can still be used.
No need to guess, some helpful people at the University of Cambridge have figured it all out for you.

As a general matter, full disk encryption systems virtually always work at the block level for multiple reasons - because disks and SSDs are intrinsically block-level devices, to take advantage of block ciphers, and so that mechanisms like block caches and Trim can still be supported. Basically, as Ric suggested a few posts above, the data path just encrypts and decrypts blocks as they fly by - all of the complexity is in the key management.
 


I don't remember seeing this back in May, but it's worth noting a Mac compatibility issue with the Samsung 970 EVO Plus SSD (which doesn't affect the plain Samsung 960 EVO version).
True. I run one of these drives on my Hackintosh, and initially there were many reports of flaky operation and crashes. Samsung does make a Linux-based bootable disk image that you can download, burn to a CD, then boot from to update the firmware. This was some months ago, so I'd imagine drives currently on the market have the new firmware by now.
 


Ric Ford

MacInTouch
AnandTech has a review of a new Thunderbolt 3 SSD and previously covered the Samsung X5:
Ganesh T S said:
OWC Envoy Pro EX Thunderbolt 3 and Plugable TBT3-NVME2TB Portable SSDs Review
... In summary, we would have liked better performance consistency for stressful writes from both the Plugable TBT3-NVME2TB and the OWC Envoy Pro EX Thunderbolt 3. However, given the price points, very few users may complain about that aspect. The thermal design for the Plugable drive is excellent, while the ruggedness of the OWC drive may make it attractive to certain market segments. By and large, the performance of the Plugable and OWC drives are equivalent, and users can make a purchase decision purely based on the best available deal at the time of purchase. On a general note, we are happy to see the appearance of economical Thunderbolt 3 SSDs in the market with high performance for real-world workloads.

The Samsung Portable SSD X5 Review - Thunderbolt 3 and NVMe in a Premium Enclosure
... Consumers would be prudent to treat the X5 as a premium product - it performs admirably for the vast majority. However, for power users who frequently transfer 100s of gigabytes in one go, a solution like our DIY Thunderbolt 3 SSD is a better choice. Our DIY device does not look as sleek as the X5, but, it is cheaper and has more consistent performance.
Amazon links:
 


It's been a long time since I invoked TRIM on my SSDs. I think it was in Sierra that I invoked it. Has anything changed since then? I also forgot the Terminal command to invoke TRIM. I don't know if any websites have been updated for Catalina. Is it still possible to invoke TRIM in Catalina and what is the Terminal command for TRIM? Thank you.
 


Ric Ford

MacInTouch
It's been a long time since I invoked TRIM on my SSDs. I think it was in Sierra that I invoked it. Has anything changed since then? I also forgot the Terminal command to invoke TRIM. I don't know if any websites have been updated for Catalina. Is it still possible to invoke TRIM in Catalina and what is the Terminal command for TRIM? Thank you.
If it's an Apple SSD, you only have to worry about a few Apple defects (for which Apple has provided repair programs and software updates), not about "invoking" Trim, which is done automatically.

For third-party SSDs, the simplest thing is to just get Disk Sensei, which will help you manage Trim (and more).
 


... I also forgot the Terminal command to invoke TRIM. I don't know if any websites have been updated for Catalina. Is it still possible to invoke TRIM in Catalina and what is the Terminal command for TRIM?
... For third-party SSDs, the simplest thing is to just get Disk Sensei, which will help you manage Trim (and more).
My Trim Tools apps will do the job. Free. I just wrote the AppleScript wrappers. They work.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts