TRIM enabler issue with two SSDs

[MatthewAMEL]

Tesselator was referring to the "Secure Empty Trash" feature of the Finder, not the ATA command "secure erase", which are two different things. You can enable Secure Empty Trash in this Finder preference pane. Or you can command-right click on the trash can to do a Secure Empty Trash. When you empty trash with Secure Empty Trash, the area that contained the data is over written.

Image

Oops.

You're right. I saw 'secure' and TRIM in the same post and went off on a rant.

 

[kevink2]

A
So the drive has no idea what NAND actually holds data that needs to be kept vs what NAND blocks can be reclaimed. This had no impact on physical spinning disks because there was no write penalty. On SSDs rewritting NAND that has existing data stored in it, incurrs a R/W penalty and can degrade performance. So you can see, without some kind of information from the OS, SSD GC routines have no way of knowing what NAND blocks can be wiped and reused. TRIM solves this by periodically letting the drive now what blocks can be reused. So TRIM can be very helpful for effective GC on a drive that's had all NAND written to at least once. How long it takes for a drive to get into degraded performance depends mostly on how much data is written to it over any period of time.

The way I understand it is that, without the Trim command, the SSD doesn't know that a given sector on the drive has good or stale data on it. You delete a file, the blocks that contained it's data become available to the OS/filesystem for reuse. Until that logical block is written to again (with new data), it assumes that it is still good, so when space is needed at the lower level, it can copy the data to a new area when it needs to make space for an erase. Or moved around for wear leveling (which essentially means that an unchanged file written to the SSD years ago, and never logically moved by a defragmentation, will still move to different physical sectors on occasion).

TRIM just allows the OS to tell the drive that a block is free without waiting.

Without trim, eventually the drive will probably think the whole partition is in use, as data is eventually written over the whole partition. Then, it has to use garbage collection to manage smaller blocks against the overprovisioning space on the drive that isn't logically visible to the OS/filesystem, but only at the drive level. So writes are always possible even it the drive is "full".

 

[VirtualRain]

The way I understand it is that, without the Trim command, the SSD doesn't know that a given sector on the drive has good or stale data on it. You delete a file, the blocks that contained it's data become available to the OS/filesystem for reuse. Until that logical block is written to again (with new data), it assumes that it is still good, so when space is needed at the lower level, it can copy the data to a new area when it needs to make space for an erase. Or moved around for wear leveling (which essentially means that an unchanged file written to the SSD years ago, and never logically moved by a defragmentation, will still move to different physical sectors on occasion).

TRIM just allows the OS to tell the drive that a block is free without waiting.

Without trim, eventually the drive will probably think the whole partition is in use, as data is eventually written over the whole partition. Then, it has to use garbage collection to manage smaller blocks against the overprovisioning space on the drive that isn't logically visible to the OS/filesystem, but only at the drive level. So writes are always possible even it the drive is "full".

I think we're saying the same thing.