Linked by Thom Holwerda on Sat 6th Oct 2012 13:59 UTC, submitted by robojerk
Linux "F2FS is a new file system carefully designed for the NAND flash memory-based storage devices. We chose a log structure file system approach, but we tried to adapt it to the new form of storage. Also we remedy some known issues of the very old log structured file system, such as snowball effect of wandering tree and high cleaning overhead."
Thread beginning with comment 537714
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Shhh!! Quiet...
by _txf_ on Sat 6th Oct 2012 16:09 UTC in reply to "Shhh!! Quiet..."
Member since:

But a bit more seriously though, this is a good thing. It's disappointing that when it comes to flash media, no suitable file system has gained popularity and we're still stuck with FAT. Well, ext2, too--

The thing here is that any block device filesystem will do for external media due to the hardware FTL (flash translation layer -- converts flash into a block device).

The post implies that this filesystem is to be used as a block device and not a mtd device. What confuses me is that they compare this to log structured filesystems, but those are usually used in mtd devices (which lack a FTL).

So what is the use case specifically for this FS?

Edited 2012-10-06 16:10 UTC

Reply Parent Score: 6

RE[2]: Shhh!! Quiet...
by galvanash on Sat 6th Oct 2012 18:32 in reply to "RE: Shhh!! Quiet..."
galvanash Member since:

From the KML, it seems some of the kernel devs are confused as well...

It seems that it does not do wear leveling and is designed to work with an FTL, but its as clear as mud to me.

I guess it will all shake out eventually. It does look interesting though:

Reply Parent Score: 5

RE[3]: Shhh!! Quiet...
by some1 on Sat 6th Oct 2012 19:23 in reply to "RE[2]: Shhh!! Quiet..."
some1 Member since:

FTL handles wear leveling, but introduces unusual performance characteristics: in-place updates become very expensive. In many cases this can be helped by file system doing copy-on-write instead of in-place update. I guess this is the idea.

That said, I thought Samsung has enough resources to proof read the documentation before submitting (at least use a spell checker). Comparison to similar file systems and some benchmark results would also help.

Reply Parent Score: 3

RE[2]: Shhh!! Quiet...
by butters on Sun 7th Oct 2012 08:36 in reply to "RE: Shhh!! Quiet..."
butters Member since:

A log-structured filesystem is not necessarily a bad design choice for FTL volumes. You don't need to worry about wear-leveling, but you don't need to worry about spatial locality either, and you know that the FTL will override any attempts to do in-place updates.

So you can only really optimize two things: allocating free (logical) blocks for writes, and indexing file extents for reads. Log-structured filesystems are as good as it gets for allocating free space (just continue writing where we left off), and they also avoid the fragmentation of files across many extents.

The only thing one might want to do differently than a classic log-structured filesystem is to update the superblocks and inodes in-place and defer to the FTL's wear-leveling algorithm. These are fixed block-sized structures, so in-place updates are simple and copy-on-write is an unnecessary overhead.

Reply Parent Score: 5

RE[3]: Shhh!! Quiet...
by galvanash on Sun 7th Oct 2012 21:02 in reply to "RE[2]: Shhh!! Quiet..."
galvanash Member since:

That makes perfect sense. Thanks for the explanation.

Reply Parent Score: 2