Log-structured file systems: There's one in every SSD

Posted Sep 18, 2009 21:02 UTC (Fri) by Yorick (guest, #19241)
Parent article: Log-structured file systems: There's one in every SSD

Does this mean that file systems that avoid overwriting live data ZFS and the like are at a
disadvantage with SSDs, assuming the firmware algorithms were tuned for NTFS and with
overwriting in mind? If the file system prefers writing updates elsewhere as long as there is
unused space, I can imagine that will cause trouble for the poor FTL.

Log-structured file systems: There's one in every SSD

Posted Sep 18, 2009 21:36 UTC (Fri) by ikm (guest, #493) [Link] (6 responses)

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 (subscriber, #51576) [Link] (5 responses)

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 (subscriber, #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 (guest, #493) [Link] (3 responses)

> 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 (subscriber, #51576) [Link] (2 responses)

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 (guest, #8471) [Link] (1 responses)

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 (guest, #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.

Log-structured file systems: There's one in every SSD

Posted Sep 18, 2009 22:02 UTC (Fri) by paravoid (subscriber, #32869) [Link] (3 responses)

That's kind of interesting, considering that Sun's OpenStorage solution (which uses ZFS) uses SSDs for caches -- which I presume has them at 100% full capacity.

Log-structured file systems: There's one in every SSD

Posted Sep 19, 2009 6:44 UTC (Sat) by butlerm (subscriber, #13312) [Link] (2 responses)

If want to use SSDs for caching the last thing you want is to keep them at
100% capacity - it takes too long to kick things out of the cache, just when
you need to put something new in.

Log-structured file systems: There's one in every SSD

Posted Sep 22, 2009 15:15 UTC (Tue) by k8to (guest, #15413) [Link]

I think the idea is they are physically at 100% capacity, even if not logically so. That is, they've probably hit full at some point.

Well, that's my guess, since it makes the most sense.

Log-structured file systems: There's one in every SSD

Posted Sep 25, 2009 14:38 UTC (Fri) by knweiss (guest, #52912) [Link]

FWIW they have separate read and write caches (both SSD).