| |||||||||||||
Log-structured file systems: There's one in every SSDLog-structured file systems: There's one in every SSDPosted Sep 21, 2009 16:14 UTC (Mon) by nye (guest, #51576)In reply to: Log-structured file systems: There's one in every SSD by ikm Parent article: Log-structured file systems: There's one in every SSD
I wondered about this, but how would it know that you didn't really want to store all zeroes in that block? When you read back from it you might find that it's been re-used in the meantime and filled with something else, or more likely the SSD firmware would complain that the (logical) block you are requesting doesn't currently map to any (physical) block.
I'm getting pretty tired this afternoon - am I missing something obvious?
(Log in to post comments)
Log-structured file systems: There's one in every SSD Posted Sep 21, 2009 16:35 UTC (Mon) by farnz (guest, #17727) [Link] It takes a little intelligence on the part of the SSD designer. Reads from a logical block not currently mapped to any physical flash must be defined as returning all zeros; once you've done that, you can treat writing a logical block with all zeros as a "free" operation, not a write. The "free" operation just marks that logical block as not mapped to any physical flash. You then know you don't need to hang onto the data that used to be important to that logical block; initially, it's still there, but when you garbage collect the physical block that used to contain the bytes from that logical block, you don't bother copying the data.
Log-structured file systems: There's one in every SSD Posted Sep 21, 2009 20:22 UTC (Mon) by ikm (subscriber, #493) [Link]
> I wondered about this, but how would it know that you didn't really want to store all zeroes in that block?
Because it's the same thing. There's no point in actually storing zeroes -- you could just mark the block as unused instead, so if later read, it would read back as zeroes.
> When you read back from it you might find that it's been re-used in the meantime and filled with something else
SSD maintains a mapping between logical disk blocks and physical flash blocks. If a logical block is marked as unmapped, it just doesn't use any physical space at all. SSD can't reuse your logical block since it doesn't "use" logical blocks -- it uses physical flash blocks.
> the SSD firmware would complain that the (logical) block you are requesting doesn't currently map to any (physical) block.
It would return zeroes, since the block is empty (unmapped). And that's the intent of it.
Log-structured file systems: There's one in every SSD Posted Sep 22, 2009 11:08 UTC (Tue) by nye (guest, #51576) [Link]
This is indeed obvious now that I'm awake (somewhat embarrassingly so :P).
I think the bit that I was somehow missing was that 'reading' from an unmapped block should just return all zeroes.
But thanks to both for making it explicit.
Log-structured file systems: There's one in every SSD Posted Oct 6, 2009 16:45 UTC (Tue) by sethml (subscriber, #8471) [Link]
The problem with this approach is that transferring zillions of zeros over the disk interface is
slow. Imagine if deleting a 10gb file took several minutes - that would be rather annoying. Too bad SATA doesn't have a "write a million zeros" command. Of course, that's effectively what a proper TRIM would do.
Log-structured file systems: There's one in every SSD Posted Oct 6, 2009 19:59 UTC (Tue) by ikm (subscriber, #493) [Link]
True. But it still might be better than the current TRIM implementation -- if not performance-wise, then at least compatibility-wise. The blocks could be zeroed in background when the I/O is otherwise idle.
|
|||||||||||||