On 2017-11-20 03:44 PM, D. Hugh Redelmeier via talk wrote:
True, but it is more complicated.
Underneath the facade of a normal HDD, an SSD does a bunch of tricky things.
Terminology (mine):
virtual block: what the disk host adapter and OS sees. Just like a block on an HDD.
real block: a chunk of flash that can hold one virtual block
erase block: the smallest unit of flash that can be erased.
- an erase block contains a lot of real blocks. Think roughly a megabyte. The collection of real blocks within it is fixed.
- only erased real blocks can be written to. And only once before they are erased again.
- real blocks can be in one of three states:
+ free (not representing any virtual block but not erased)
+ erased (not representing any virtual block, erased) Note: an erased real block is not an erase block (it will be inside an erase block).
+ in-use (representing a virtual block)
- in the real hardware, you can never update a block in place. So when a program writes to a virtual block, a real, erased block is written and some book-keeping is done.
If the write was to a virtual block that was represented by a real block, that real block becomes free: there is no way for the computer to reference it, so it need not be preserved.
- the SSD firmware keeps track of erased blocks. When it runs out, it does a garbage collect phase to find unused blocks. If it finds that a whole erase-block is full of free blocks, it will erase that block and add it to the free pool.
But that isn't normal. Normally, an erase block is like swiss cheese and the good stuff has to be moved to an erased block to allow their former erase block to be erased.
As you can see, a write to a block might precipitate as much as 1MiB of actual writes. That's called "write amplification" and it is can wear out SSDs quite seriously. And it will slow things down a lot.
- how does the drive firmware learn that a physical block is free?
+ a block on an SSD is born free
+ a write to a virtual block will cause a write to a newly allocated physical block AND implicitly make the old physical block free (but not erased!)
+ deleting a file on an SSD causes its virtual blocks to be free, but the SSD firmware does not know that until a trim command tells it.
Consequences:
- having a lot of free physical blocks cuts down on write amplification
- the effect is non-linear
- to increase the number of free blocks
+ use trim * fstrim(8) * trimm option to mount
+ allocate less of the disk drive for OS use. But, if it isn't a new disk, you have to tell the SDD firmware that the free space is free. I don't know how to do that.
One of the better write ups that I've seen about SSDs in general and and over-provisioning specifically: https://www.seagate.com/ca/en/tech-insights/ssd-over-provisioning-benefits-m... Cheers, Jamon