Comment # 9 on bug 1043602 from Stanislav Brabec

I just consulted some details with kernel developers.

FITRIM kernel command is the command that sends hints about garbage blocks to
the drive. SATA 3.0 does not yet support queued trim, so each TRIM command
causes performance drop.

Starting with SATA 3.1, performance impacts will be lower.

Typical speed of the TRIM is 1GB/sec. Discs probably don't actually perform the
erase, just mark and delay for idle time.


SSD discs support two different commands:

TRIM: This is a hint to the drive that the block is garbage.

SECURE ERASE: This is the command to immediately erase the block.

There is no guarantee, that drives really implement two different algorithms
for these commands, and that TRIM does not cause extensive block moves.

Imagine a situation, when you have two blocks with 50% of garbage. In case of
TRIM, the drive can decide, whether it will only mark blocks as garbage, or
move these blocks to create one full block and one empty, and whether to erase
it immediately.

Additionally, TRIM use may cause that SECURE ERASE is insecure, as it erases
only the current location of the data block, but TRIM may leave block just
marked as garbage, prepared for later (time-expensive) erase.


If your SSD implements "lazy trimming", it has nearly no impact to the
lifetime, but also only a little impact to the performance after trimming.
Starting with SATA 3.1, you can call fstrim on such discs as often as you want.

If your SSD uses the same algorithm for both TRIM and SECURE ERASE, lifetime
can easily drop twice or even much more (erase block / blocksize in a
theoretical worst case), but once trimming is done, it can run significantly
faster.

If you SSD implements something between that, cost/benefit ratio will vary.

As a result of these facts, everything about TRIM is just a guessing.


Implementing data amount based TRIM sounds like a better compromise than
interval based. E. g. 60% of disc capacity was written since last TRIM => call
TRIM.