Comment # 8 on bug 1043602 from Stanislav Brabec

Well, as it is a sensitive area that can affect hardware lifetime, I do not
want to diverge from the upstream.

As a user of a standard SSD, you don't see internal processes of each write or
TRIM command.

Typical Flash memory has three sizes of blocks:
- Read block: typically tens of bytes
- Write block: typically kilobytes. It can change bits in one direction.
- Erase block: typically hundreds of kilobytes. It can change bits in reverse
direction.

Standard sector write means abandoning of the old sector contents and flagging
it as garbage, allocation of a new clean block, writing, and remapping the
block.

When SSD runs out of clean blocks, it attempts to find a complete erase block
with all sectors flagged as garbage.

If no such block is found, SSD has to pick one half-full erase block, move live
blocks outside to get an completely free erase-block.

In worst case most of erase blocks are nearly full and the device needs to
re-allocate tens of sectors just to get one erase block. Once erase block is
allocated, it is erased, one sector is written, and the rest is ready for
further use.

In case of TRIM, SSD moves used sectors out of erase blocks that contain
garbage, and then pre-erases them. In the worst case mentioned above, it means
that the >90% of the whole contents of the SSD has to be re-allocated.

The worst case happens in case of nearly full disc and random writes of small
chunks of data once per each erase block.

Real life algorithms are often even more complicated, as it attempts to spread
writes evenly over all cells.


Linux has absolutely no control over the proprietary wear leveling processes
inside the SSD.