Announcement

Collapse
No announcement yet.

Linux 4.4 SSD Benchmarks On EXT4, F2FS, Btrfs & XFS

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

  • Linux 4.4 SSD Benchmarks On EXT4, F2FS, Btrfs & XFS

    Phoronix: Linux 4.4 SSD Benchmarks On EXT4, F2FS, Btrfs & XFS

    For those looking toward some fresh comparison numbers of EXT4, F2FS, XFS, and Btrfs on solid-state storage, here you go...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Feels like BTRFS is going nowhere.

    Comment


    • #3
      Originally posted by deadite66 View Post
      Feels like BTRFS is going nowhere.
      You generally install btrfs for it's features, not necessarily it's performance.
      But I agree, on most of my boxes I got rid of btrfs in favor of f2fs and ext4.
      I kinda wish that they have added lz4/lz4hc compression into btrfs, tho I have no idea how well these perform on small blocks.

      Comment


      • #4
        So I want to buy some cheap SSD to put in a laptop. What is the state of support for the TRIM command in Ubuntu (or Linux in general) outside Intel and Samsung SSD's? Sandisk and Kingstone are well supported? Because I don't want to spent much in a machine I barely use.

        Comment


        • #5
          I doubt it would make a big difference, because as far as I remember lvm is very minimal aproach, but I think it would be very unrealistic that most people use ext4 on normal partitions, it makes shrinking/growing of the fs, a terrific act.

          So I wonder how much it would change the benchmarks if you would use lvm for the non btrfs filesystems.

          And btw was compression used in this example also basicly something everybody that uses btrfs especialy for root/home would want to activate in any case. I heard ext picked that up too? but neven seen some benchmarks, or something in real life is it in a productive secure state?

          the problem is I guess that the quirks of btrfs are high (that said your data is pretty safe, had no loss at all in last years) but the tools to use the advanced features are rare.

          But still the question is how much does performance really matter. I mean for what reason do I use ramfs for /tmp and profile-sync-daemon for browser profiles. so that the fs speed does mostly not matter at all, because how fast your fs hd/ssd ever is it is still much much slower than your ram.

          A good example is for me GuixSD, it works today without btrfs or other snapshots but it basicly snapshots your system data on each upgrade, so how fast would it be to realise this feature with btrfs snapshots I guess here btrfs would be much faster then ext4 and symlinking.

          Then there are stuff like dedublication and stuff like that. just saying stuff like that we heard from the systemd guys, its nice to see that guixsd can do that without a snapshot feature but at some point btrfs should outperform all this external tools because it can do stuff on a lower level, like every userland-fs is slower than a real kernel-fs.
          Last edited by blackiwid; 03 December 2015, 05:04 PM.

          Comment


          • #6
            Still using ext4 on plain partitions. And it still comes out as the most well-rounded fs of them all.
            My kernels are built to match, all powersave, c-states and other crap turned of. Weighs in at 3 Megabyte with all modules needed, no external ones. Greased lightning.. etc.

            Comment


            • #7
              I'm pretty sure I saw a big list of "tested" SSDs somewhere on kernel mailing list (or wiki), just google for it. IIRC TRIM problems are mostly thing of the past, I have few CZC cheap SSDs (best price / GB I could find) and they run just fine even on high IO system.
              It's proaly safest to do a bit of googling to be sure you are not in that small percentage of systems with problems, but it should be just fine.

              I had some corruption of F2FS about a year ago, but I run linux-next trees on most of my machines so it's to be expected.
              Also, I only have system on F2FS, 'real' data is still stored on ext4.

              Comment


              • #8
                Actually which linux operating system akkows f2fs file sysyem option during installation!?

                Comment


                • #9
                  I like that XFS performance, they're outperforming all the others in so many tests. I woulda thought F2FS would take the cake here but seems like it's more of a race between XFS and EXT4 with F2FS in tow and BTRFS falling way behind. Not that I ever had any faith in BTRFS to begin with. Ever.

                  Comment


                  • #10
                    Originally posted by tpruzina View Post

                    You generally install btrfs for it's features, not necessarily it's performance.
                    But I agree, on most of my boxes I got rid of btrfs in favor of f2fs and ext4.
                    I kinda wish that they have added lz4/lz4hc compression into btrfs, tho I have no idea how well these perform on small blocks.
                    I have lz4 support patched into btrfs on one of my systems. I've forward ported the old integration work to the current kernel. Works well. Never managed to get lz4hc working properly though, there's a bug which causes an inability to decompress from lz4hc files on occasion which I just haven't been able to pinpoint. That's probably why it never made it into the official version.

                    Comment

                    Working...
                    X