4 ms·

Flash memory does not erase during user actions. TRIM is done async

by malfist 3y ago

thebruce87m 3y ago
It’s a good point, but the blanket statement isn’t true. Not all flash memory devices support TRIM.
ssl-3 3y ago
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 3y ago
  > 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 3y ago
    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.)

4 ms·

Flash memory does not erase during user actions. TRIM is done async

by malfist 3y ago

Flash memory does not erase during user actions. TRIM is done async

thebruce87m 3y ago
It’s a good point, but the blanket statement isn’t true. Not all flash memory devices support TRIM.
ssl-3 3y ago
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 3y ago
  > 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 3y ago
    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.)