Recent Features
| |||||||||||||
Zero = trimZero = trimPosted Aug 21, 2009 1:58 UTC (Fri) by dmag (subscriber, #17775)In reply to: Zero = trim by ncm Parent article: The trouble with discard
Writing zeros to a block isn't the same as writing zeros to flash. Flash is unreliable, so you need checksums, wear leveling, etc. So a block of zeros isn't really zero. This extra stuff used to be done in hardware (CompactFlash), but nowadays is done in software (SD cards).
What's worse, flash chips are always "FF" in their erased state. So to write all zeros, you'll have to erase the block, write zeros, then later erase it and write real data. If you wrote FFs, it would only have to erase it once. But the zeros can't be at the block layer.
I agree with the article -- if we pretend flash is "just like a hard drive", we will be using the hardware sub-optimally.
(Log in to post comments)
Zero = trim Posted Aug 21, 2009 3:02 UTC (Fri) by foom (subscriber, #14868) [Link] 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.
Zero = trim Posted Aug 23, 2009 19:58 UTC (Sun) by dmag (subscriber, #17775) [Link]
I still don't think that's the best way to do it.
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 Posted Aug 27, 2009 17:57 UTC (Thu) by robert_s (subscriber, #42402) [Link]
"but nowadays is done in software (SD cards)."
No. SD cards have their flash translation layer on the card in hardware.
What you're thinking of is CF cards have a whole ATA interface on the card too ( the actual interface is closely related to PCI ).
|
|||||||||||||