Mark Christiansen (aliasundercover@nospam.net) on 1/22/11 wrote:
---------------------------
>It appears to my inexpert view the chief benefit of trim is giving the SSD's load
>leveling and block coalescing algorithms more space to work in. I wonder how long
>the tail of benefits may be as in how much does more free space improve controller
>performance as the percentage of free space increases. Does 10% free space give
>95% of the benefit?

10% extra free space is a hell of a lot better than having TRIM, because TRIM only makes hitting the worst case less likely, but can't prevent it. Or in other words, extra reserve is always good, while TRIM depends on the IO pattern.

> Or does can more free space make a material difference? Or
>perhaps it varies by how the SSD gets used.

That too.

>It would seem that given a load likely to stress the SSD's work in this area one
>might deliberately use a smaller portion. Perhaps in the quest for marketing stats
>some SSDs go too cheap on their reserved area. If the SSD is sold as 256MB but
>that is inflated by reserving too little working space one might simply give 192
>MB to the filesystem and never touch the rest.

If space is more important than performance, use a low reserve percentage (the standard 7% from power-of-two to HD power of 10 trick + round down to nearest ten GB: e.g. 128GB real -> 120GB marketing is IMHO the minimum). If the disk is going to be used for lots of random write IO and is expected to fragment a lot, you really want a high reserve percentage to keep performance up.

Best is if file systems are aware of this and only use the end of the disk when they really need it, so users don't have to manually create a smaller partition table than the disk to improve performance.

NAND flash chips more or less come in multiples of 8GB, so
you can usually guess what reserve ratio a disk has. If it's sold as a "256GB" disk I wouldn't buy it because performance is clearly not a priority. It should be sold as 250 at most.

> The SSD controller will of course
>work with its whole flash area garbage collecting and load leveling while the file
>system will be guaranteed to never wind up in the low free space bad performance domain.

Yes, you're correct. How much difference it makes it hard to tell because it depends on the IO pattern, but the theoretical worst case is easily calculated as:

Min write speed = Reserve percentage / 100 * Max write speed.

And this doesn't include the extra overhead of erasing blocks or other inefficiencies, just the garbage collection that needs to be done.

It's a trade off between disk space and performance, not something you usually know beforehand, and can't expect users to know and care about. That's why it's best if this is basically done in the file system (there was a quick ext3 patch to reuse blocks as much as possible, but no idea what the current default behaviour is).