[ssl-3]

Flash memory is always erased during user-initiated writes in instances where trim is not used, or when there are not enough known-erased blocks to hold the write -- for whatever reasons these conditions may exist.

At a low level, a block of flash can't be written without being first erased. It might have been erased previously (which is ideal), but it might also might need to be erased immediately (which is much slower) in order for to perform a write operation.

And a trim command doesn't guarantee erasure of a low-level flash block -- it's up to the controller to sort out that out on its own.

[thebruce87m]

> Flash memory is always erased during user-initiated writes in instances where trim is not used

Great answer but slight nit pick: In my world (embedded) the flash on (some? dare I say most?) microcontrollers is only erased when you specifically tell it to erase. You can write to sectors multiple times without erasing. You can even write to the same word multiple times, as long as you only want to turn 1’s to 0’s. If you want to turn any 0 to a 1 in the whole sector then that’s when the erase comes in.

This gives interesting use-cases where you can count up using individual bits without a time-consuming/power-using/cycle-consuming erase.

[ssl-3]

Solid nit pick. I appreciate it.

(And somewhere in the back of my head I knew of this method of writing useful things to flash. It certainly has at least a couple of efficiency advantages that can be important in some cases, even if they're not the kinds of things that would be important or even usable with a consumer-oriented flash device that is operated from a high level.)