Announcement

Collapse
No announcement yet.

F2FS In Linux 4.19 Will Fix Big Performance Issue For Multi-Threaded Reads

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • F2FS In Linux 4.19 Will Fix Big Performance Issue For Multi-Threaded Reads

    Phoronix: F2FS In Linux 4.19 Will Fix Big Performance Issue For Multi-Threaded Reads

    The Linux 4.19 kernel updates for the Flash-Friendly File-System (F2FS) should bring much faster performance for multi-threaded sequential reads -- as much as multiple times faster...

    http://www.phoronix.com/scan.php?pag...FS-MT-Read-Fix

  • #2
    Is it advised to use F2FS on an SSD SATA drive?

    In theory, I understand why F2FS could be great, but in practice I've never seen something worth using this FS in the benchmarks.

    Comment


    • #3
      I consider switching from btrfs to f2fs on HP Stream 7 Tablet, but I not sure if it make sense for emmc storage, as there is not enough benchmarks for this particular storage type. I expect it could be big win for seq read and writes, but does it make sense from overall system performance point of view? For faster applications startup, web-browser cache access speed increase, and such stuff.

      Comment


      • #4
        Why is called F2FS and not F3S?

        Comment


        • #5
          Originally posted by George99 View Post
          Why is called F2FS and not F3S?
          I suppose they wanted to keep explicit FS in the name. So FFFS became F2FS.

          Comment


          • #6
            Small typo
            Originally posted by phoronix View Post

            "With multi-threaded sequential reads the read throughput goes up fro"

            Comment


            • #7
              Originally posted by RussianNeuroMancer View Post
              I consider switching from btrfs to f2fs on HP Stream 7 Tablet, but I not sure if it make sense for emmc storage, as there is not enough benchmarks for this particular storage type. I expect it could be big win for seq read and writes, but does it make sense from overall system performance point of view? For faster applications startup, web-browser cache access speed increase, and such stuff.
              Afaik, f2fs shines where the storage controller sucks, which means that in eMMC it should still be better than other filesystems. Most Android devices (which is the official usecase for this filesystem) are all using eMMC of some sort since like 2014 at least.

              Also on SDCards and on usb flashdrives it should provide the most performance difference vs a normal filesystem.

              On half-decent Sata or even M.2 SSDs.. not so much as there you have a ridiculously powerful storage controller that is designed to deal with garbage-grade filesystems like NTFS already.

              Comment


              • #8
                Originally posted by starshipeleven View Post
                Afaik, f2fs shines where the storage controller sucks, which means that in eMMC it should still be better than other filesystems. Most Android devices (which is the official usecase for this filesystem) are all using eMMC of some sort since like 2014 at least.

                Also on SDCards and on usb flashdrives it should provide the most performance difference vs a normal filesystem.
                Thanks! Will try then.

                Comment


                • #9
                  Originally posted by starshipeleven View Post
                  Afaik, f2fs shines where the storage controller sucks, which means that in eMMC it should still be better than other filesystems. Most Android devices (which is the official usecase for this filesystem) are all using eMMC of some sort since like 2014 at least.

                  Also on SDCards and on usb flashdrives it should provide the most performance difference vs a normal filesystem.

                  On half-decent Sata or even M.2 SSDs.. not so much as there you have a ridiculously powerful storage controller that is designed to deal with garbage-grade filesystems like NTFS already.
                  I don't see why not having extensive RAM and controllers to accommodate for unfit filesystems is a valid critism of eMMC.

                  At the end of the day, NAND-Flash is alot different to regular storage, as a single byte written can cause a ~2Mbit page to be red, erased and written back. Apart from the horrible performance, this will also wear out the write-cycles.
                  Filesystems catering for those characteristics (like E2FS) wont need a overly complex controller, and should still cause less overhead writes to Nand pages.

                  Comment


                  • #10
                    Originally posted by RussianNeuroMancer View Post
                    I consider switching from btrfs to f2fs on HP Stream 7 Tablet, but I not sure if it make sense for emmc storage, as there is not enough benchmarks for this particular storage type. I expect it could be big win for seq read and writes, but does it make sense from overall system performance point of view? For faster applications startup, web-browser cache access speed increase, and such stuff.
                    I've got a bit of experience with F2FS (mostly on my Pi as it is a bootable FS there even without any initrd because it's precompiled in the kernel),
                    got tons of experience with BTRFS from embed (data partition on Pi) all the way through smartphones (Jolla) and up to servers.

                    BOTH are file system that attempt to avoid in-place over writes as much as possible because that where most flash sucks (it leads to a write amplification : erase the whole erase block, write the new write, re-write again all the other bits of the erase blocks that weren't in the current write).

                    F2FS does it by being a log-structured file system (i.e.: the filesystem itself is the log, most write are append-only - think multisession CD - with the older parts eventually getting garbage collected. Thus rarely any over-write). As far as I've read, F2FS tries to optimize as much as possible by keeping a cache in ram and grouping writes (and over-writes), so that an I/O intensive software doesn't blow up the log but instead only writes a final copy at the end.
                    (So database-type "lots of random writes" doesn't suck too much in theory).

                    BTRFS does so by being a copy-on-write system : it never overwrites. It always writes a new copy of the data elsewhere, and only then (once the data is updated) it updates the pointers (and thus snapshots come literally for free : they are just 2 pointers point to 2 different versions !)
                    Performance wise, it's on the slower side, mainly because it tries to cram more features, like checksum of *everything* (not only the metadata) - that's great for data integrity, (it's one of the few FS offering this) but that its CPU and bits of IO. it also provide optional compression, great for saving bandwidth and space, but eats CPU (and latency).
                    Basically, BTRFS is in the same class as ZFS, whereas F2FS is in the same class as EXTn.

                    BTRFS might also potentially suffer from the "lots of random writes" problems, like any other non-overwriting filesystem. You basically got 3 otpions :
                    - mount with "autodefrag" which tries to detect and group together multiple writes (a bit like F2FS does) which might help mitigate the problems.
                    - manually "btrfs fi defrag" a single file that has become a too big labyrinth of indirect pointers.
                    - mark some files with extended attribute "+C" (no CoW) which is the way to go with large files with lots of random writes that usually feature their own internal integrity (databases, virtual machine disk images, torrent of large files, etc.)
                    (NOTE: you can't directly "chattr +C" a large file, only empty ones. So you need to "touch" to create a new empty, then "chattr", then "cat" to append the data from the original. Don't forget to check chmod/chown)
                    - mount a whole partition as nocow, which is a bit stupid because you lose one of the key characteristic of btrfs.

                    BTRFS eats more memory than F2FS (but comes with more features).

                    Warning: RAID5/6 on BTRFS still isn't considered as production-ready for environments where powerloss can happen. Use other raid modes instead.

                    Both F2FS and BTRFS being "never overwrite" systems means that even in case of powerfailure, you can usually recover an older version of the data.

                    Comment

                    Working...
                    X