Zero = trim
Zero = trim
Posted Aug 21, 2009 3:02 UTC (Fri) by foom (subscriber, #14868)In reply to: Zero = trim by dmag
Parent article: The trouble with discard
But the point is that you wouldn't *actually* write the block of zeros to the flash. Since all reads/writes to the flash disk go through a remapping layer, it would be trivial to treat all-zero writes specially, and not write them out at all, but just mark them as zeroed in the block-map.
Posted Aug 23, 2009 19:58 UTC (Sun)
by dmag (guest, #17775)
[Link]
Summary of the Problem:
The FS layer is the layer that knows what's free and what is real data. But the FS layer doesn't get any requests to write the the "free" space (by definition), so the block layer will never get any writes to that space. The block layer (or the driver) is currently doing a lot of work to preserve (wear leveling) that "free" data, even though we know it is "don't care" data.
Your proposal is "what if the FS layer could inform the block layer about free space by writing zeros there?". But there are some problems:
- First, you need an API change to know when it's OK to do those extra writes. Otherwise, you will kill non-compliant flash disks or hard drives. (slow down with useless writes, wear out with extra writes, etc.)
- Second, there ARE times you want to actually write out zeros in a block (think of the case where you are writing to a USB stick that will go in another computer, or security). So now you need an API change to say "This is not a phantom write"
- Third, the block/device layer will have to look at the data in the block to detect the zeros, which will kill performance. Normally, the block layer will just poke the address into a DMA controller and get on with life. What you are proposing would require the block layer to scan the block, which will evict everything from the L1/L2 cache.
Since we have to change the FS to Block/Device API anyway, we may as well invent a real communication channel instead of trying to piggyback on "all zeros".
Zero = trim