On Dec 13, 2013, at 12:49 PM, Carl Hoefs <[email protected]> wrote:
> What is the current status of TRIM (for spatially distributing writes to SSD > drives so they last longer) on OS X? > > Is it still the case that OS X has TRIM enabled only for Apple-preinstalled > SSDs? > > Is it still necessary to utilize a "TRIM enabler" app if the boot HDD is > swapped out for a third-party SSD? > > Is enabling TRIM an option for external non-boot SSD drives? Up until rev 3.1, the SATA spec is fundamentally flawed because TRIM is a non-queuing command, meaning that all other read/write requests must be cleared (and held) from the queue before the command is issued. So it's going to take a while for drives that implement the queued TRIM command in SATA rev 3.1, and presumably this also requires SATA rev 3.1 controllers as well. Another issue is that drive firmware implementations are all over the map. Many aggressively erase and/or move data around within the SSD, upon receiving TRIM commands, and this too slows things down. Still others use erase block size as the TRIM granularity size, and of course the drive has no way to communicate this except maybe buried in some drive model spec. Firmware makes a huge difference in SSD behavior. Further source of behavior variation is whether the file system or logical volume manager (Core Storage, i.e. Fusion and FileVault2) implement delayed TRIM queuing, whereby LBAs subject to TRIM aren't immediately TRIMmed, but rather the command is issued when the SSD is idle. I don't know whether either HFS+ variants, or Core Storage, or the SATA driver layer implement delayed TRIM on OS X. I have some anecdotal evidence suggesting that Core Storage issues TRIM to FileVault2 physical devices, which actually isn't such a good thing if true. In the short term, your workload is the first indicator of whether TRIM even applies. If you're mostly creating or rewriting existing files, TRIM isn't even used. The SSD knows LBA's (re)written to make the underlying physical page obsolete, and the LBA is assigned a new physical page that's already been erased. The old page is marked for erase. TRIM is useful when files are deleted because it informs the SSD those pages don't need to be migrated for wear leveling, or cause delay in erasing an erase block. For HFSJ/HFSX directly on the physical device, I think it'd be sufficient to issue a single fstrim once a day as part of periodic daily. If we had an fstrim command. That's sufficiently frequent. Even once a week is probably OK for most usage patterns. But for Fusion and FileVault2, due to Core Storage also employing COW, it's probably a different story where a lot of pages are made obsolete in the course of normal writes because these aren't rewrites so the SSD isn't informed except via TRIM. Through designed overprovisioning in the device, and/or by partitioning the SSD leaving ~20% unallocated, or simply leaving 20-30% of the file system free, the drive is eventually (passively) informed of pages that can be erased, and that will maintain the performance of the drive. It is still the case that Apple is only enabling TRIM on their SSDs. Meanwhile it's not a default on Linux distros, although Ubuntu has recently said they're going to start doing doing this by default. Windows has been issuing TRIM to all model drives, as far as I know they don't have a blacklist, by default, although there's a way to disable it. Define external SSD? If you mean by Firewire the answer is probably no, because there are few chipsets in existence that passthrough this and other SATA commands like the SMART and security command sets. If Thunderbolt or eSATA then yes the ATA TRIM command physically can get to the SSD, but it'd have to be enabled in the AHCI block storage driver, which again for non-Apple drives it isn't enabled by default. Chris Murphy _______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
