Yes -- but that stops to matter the moment you fill up your NTFS with data completely just once. After that there would be no difference whatsoever -- all the blocks are marked as used anyway.
I guess there are some people out there who never ever happen to use their drive to full capacity (imagine a person using Word to type documents and IE to surf the web, and doing nothing more than that) -- I guess that's what Valerie has been referring to. In-place filesystems should be beneficial to such kind of people, of course.
Btw, I strongly happen to believe that most SSDs would mark blocks as free if they are written as zeroes -- just because full NTFS format would mark all blocks as used otherwise.
Log-structured file systems: There's one in every SSD
Posted Sep 21, 2009 16:14 UTC (Mon) by nye (guest, #51576)
[Link]
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-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.