Slashdot Mirror


Samsung Creates New File System F2Fs For Linux & Android

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."

6 of 140 comments (clear)

  1. Re:SSD Drives by Anonymous Coward · · Score: 5, Informative

    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.

  2. It's not for bare NAND by bogolisk · · Score: 5, Informative

    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.

    --
    Bogus
    1. Re:It's not for bare NAND by romiz · · Score: 5, Informative

      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.

  3. Re:I wonder how it is to be used by Jerome+H · · Score: 4, Informative

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

    --
    int main() { while(1) fork(); }
  4. Re:Remember when this was unthinkable? by Xtifr · · Score: 4, Informative

    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.

  5. RFS by thegarbz · · Score: 4, Informative

    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.