Samsung's F2FS filesystem

Posted Oct 8, 2012 19:52 UTC (Mon) by khim (subscriber, #9252)
In reply to: Samsung's F2FS filesystem by jpfrancois
Parent article: Samsung's F2FS filesystem

What do you mean by FTL ?

Flash translation layer.

Does Flash Transition Layer includes wear leveling management for you?

Yes.

The role of F2FS is not very clear from the announcement. How can you be "Nand Friendly" if you work on a system were the "FTL + wear leveling handling" does everything to hide the Nand ?

FTL is supposed to transparently hide the nature of flash under it. But this layer is extremely leaky. So it makes perfect sense to design filesystem which makes it happier. Well, it's only makes sense in a world where devices with untrunoffable FTS exist, but, for better or for worse, this is exactly how our world is.

Maybe there are some well known limitations to the FTL found in the typical SD card, but I don't know them, so it is not clear to me how F2FS happens to be Nand friendly, when precisely the nand characteristic are carefully hidden by the SD card embedded controller.

It's impossible to hide them. The fact that flash erase block are much higher than write blocks is central feature of flash and it can not be ever fully hidden. Any somewhat sane FTS will handle sequential writes just fine and random writes worse. To the degree that it's speed will drop 10 or 100 times beyond certain threshold. Random reads are fine. These two fundamental, unfixable characteristics are enough to design a filesystem.

Samsung's F2FS filesystem

Posted Oct 10, 2012 9:05 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]

"It's impossible to hide them. The fact that flash erase block are much higher than write blocks is central feature of flash and it can not be ever fully hidden. Any somewhat sane FTS will handle sequential writes just fine and random writes worse. To the degree that it's[sic] speed will drop 10 or 100 times beyond certain threshold. Random reads are fine. These two fundamental, unfixable characteristics are enough to design a filesystem."

Not really. The FTL is basically a complete file system of its own, and like "normal" file systems, their designs and on-medium format can vary wildly. You have no idea how a given FTL will handle sequential vs. non-sequential writes. Some of them are basically log-structured and don't care a jot about the difference. New writes can just be thrown out to the next available area of flash as they arrive, regardless of the logical sector number which is being written. And there's a boatload of RAM for a lookup table to make writes go fast. Power-up is slow, but hey, that's why we have the SATA 'Device Sleep' work to essentially allow the drives to suspend-to-RAM and not have to build the whole table again when they wake up.

The only really fundamental thing you can know is that you need some kind of TRIM mechanism to tell it that you no longer care about the contents of certain sectors, otherwise it'll faithfully copy that obsolete data around the flash as it garbage collects, causing lots of lovely write amplification and shortening the lifetime of the flash. It's a shame that TRIM is such a performance problem in many current implementations...

What you actually want to do is group long-term stable data together into the same flash eraseblocks, and short-term volatile data together into other eraseblocks. That way, when we need to do garbage collection to reclaim dirty flash space, we can make maximum progress for the least amount of copying. But you basically have no idea how to do that on an FTL which is a black box.