Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×
Data Storage Android Linux

Samsung Creates New File System F2Fs For Linux & Android 140

sfcrazy writes "Samsung has created a new Linux file system called F2FS. Jaegeuk Kim of Samsung writes on the Linux Kernel Mailing List: 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."
This discussion has been archived. No new comments can be posted.

Samsung Creates New File System F2Fs For Linux & Android

Comments Filter:
  • Re:SSD Drives (Score:5, Informative)

    by Anonymous Coward on Friday October 05, 2012 @03:53PM (#41562189)

    No. SSDs present themselves to the OS as contiguous block devices. Filesystems intended for bare NAND flash like jffs(2), yaffs, and this new F2Fs would be totally useless for SSDs. They're intended for bare NAND, which SSDs are not.

  • by bogolisk ( 18818 ) on Friday October 05, 2012 @04:07PM (#41562325)

    No. SSDs present themselves to the OS as contiguous block devices. Filesystems intended for bare NAND flash like jffs(2), yaffs, and this new F2Fs would be totally useless for SSDs. They're intended for bare NAND, which SSDs are not.

    You're wrong

    f2fs work on top of block devices. f2fs sends TRIM (ATA command) down to the device. Bare NAND flash doesn't grok ATA commands.

  • Re:SSD Drives (Score:3, Informative)

    by Anonymous Coward on Friday October 05, 2012 @04:08PM (#41562335)

    SSDs are NAND, but they are not bare NAND. They have control circuitry which manages the problems with NAND (e.g. bad blocks), and presents the drive as a contiguous block of good storage.

    These filesystems are all for bare NAND, not SSDs, which include NAND, but are not bare NAND.

  • by Jerome H ( 990344 ) on Friday October 05, 2012 @04:33PM (#41562603)

    You can find a lot of details in the txt file: https://lwn.net/Articles/518719/ [lwn.net]

  • by Xtifr ( 1323 ) on Friday October 05, 2012 @04:42PM (#41562727) Homepage

    No, I don't. I remember when it was rare, but not when it was unthinkable. Even if you mean copyleft as opposed to merely open-source (there was and is a lot more reluctance about copyleft), commercial hardware companies were contributing to the GNU project even before the Linux kernel sprang into existence. GCC has always had the backing of hardware companies. The GCC Ada backend was fully funded by commercial companies several years before Linus went public with his experimental kernel.

    Heck, some companies even recognized that the GPL protected their own code, even before Linux appeared. The GPL'd versions of Ghostscript existed because Aladdin recognized that the GPL prevented others from taking unfair advantage of their code, while still allowing the community to contribute.

  • by romiz ( 757548 ) on Friday October 05, 2012 @06:11PM (#41563665)
    The problem is that even with a translation layer for block access, flash-based devices have limitations, which means that different usage patterns can dramatically change the performance of the device.

    For a (simplified) example, to write a file in ext3, you need to store the new data for the file, but you also need to store other metadata: the location of the data blocks themselves in the inode, the file size in the directory, the journaling data. This means that you have four 'internal block descriptors' open for writing at the same time.

    But block descriptors are a limited resource in SSDs, and even more so for low-cost eMMC devices. This means that with only two or three open files with regular writing, you could quite easily lead to some kind of thrashing state, with the device quickly opening and closing descriptors. Since flash memory writing is strongly constrained, this means that a whole block (2 MiB block size is common) containing a descriptor will need to be erased before its next use. As a result, each block only contains little interesting data, and writing only a small amount of data leads to a lot of flash write and erase access. This problem is called write amplification, and reduces both the disk's performance and its durability.

    The F2FS design is a log-based design, where all files on the disk share 6 common writing areas, for each kind of stored data, where the information is stored as it arrives. This will have a very positive effect against the write amplification problem, and is an example of how an adapted file system can have a positive impact, even on block-based devices.
  • by shutdown -p now ( 807394 ) on Friday October 05, 2012 @06:22PM (#41563825) Journal

    Windows has some built-in support for MTP (at least since Vista), though it's not on FS level - instead, it's hooked up into Shell/Explorer, much like Libraries in 7. So if you're content with Explorer, or some file manager that's using Shell interfaces, then it should just work.

    For automation, when you actually want to see it as FS, yeah, it's a mess. Ideally a driver-source-compatible port of FUSE would solve this, and people have made several attempts at FUSE-Win32, but apparently writing Win32 FS drivers is not for the faint of heart, so I don't know of anything stable.

  • RFS (Score:5, Informative)

    by thegarbz ( 1787294 ) on Friday October 05, 2012 @07:27PM (#41564443)

    While the primary benefit will initially be for Android devices, this will be great news for solid state drives as well. Great job Samsung!

    Before you go congratulating them on a great job, remember this is the second time they did this. The original attempt was called Robust File System. It was an abortion based on FAT16/32 with a duplicated file allocation table and some sort of journalling hacked on top.

    It was claimed to be optimised for NAND devices and all that other good stuff, but the community quickly came to rename it Really Fucking Slow.

    This file system was so slow that on the original Galaxy S the kernel would think software locked up while writing to the disk and prompt the user to force close the device. Search for "lagfix" if you're interested in what a disaster this was. There were users world wide trying to find fixes for the slow system performance, and the fix was often in the form of a kernel which supported ext4 or yaffs and a utility which converted the entire /system and /data partitions in the phone to the more common file systems.

    I don't have high hopes in Samsung's competence here.

  • Re:SSD Drives (Score:4, Informative)

    by repvik ( 96666 ) on Saturday October 06, 2012 @06:20AM (#41566829)

    Bare NAND is presented as a block device. NAND SSDs are also presented as block devices. That does not imply that they are equal. SSDs have a controller that does remapping on the fly, in many cases on the fly compression, bad block handlling and much more. Bare NAND does not have that layer. That is why the ACs comment should be moderated informative, and you should be moderated "plain wrong".

"We shall reach greater and greater platitudes of achievement." -- Richard J. Daley