Announcement

Collapse
No announcement yet.

BcacheFS vs. EXT4 vs. Btrfs vs. XFS vs. F2FS

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

  • BcacheFS vs. EXT4 vs. Btrfs vs. XFS vs. F2FS

    Phoronix: BcacheFS vs. EXT4 vs. Btrfs vs. XFS vs. F2FS

    Yesterday I posted the first independent benchmarks of the Bcachefs file-system, the new file-system aiming for EXT4/XFS speed while having Btrfs/ZFS-like features. Here are some more benchmarks...

    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
    tl;dr : just stick to using ext4

    Comment


    • #3
      Originally posted by gotwig View Post
      tl;dr : just stick to using ext4
      I'd rather stick to btrfs; I've had too many silent corruptions with ext4.

      Comment


      • #4
        Originally posted by macemoneta View Post
        I'd rather stick to btrfs; I've had too many silent corruptions with ext4.
        And btrfs just makes the disk unmountable with ctree or extent corruption. I've been maining btfrs for about three years but in that time my disks have died at least a dozen times. I always keep backups at least.

        Comment


        • #5
          Originally posted by zanny View Post

          And btrfs just makes the disk unmountable with ctree or extent corruption. I've been maining btfrs for about three years but in that time my disks have died at least a dozen times. I always keep backups at least.
          None of our btrfs systems has had a problem over the last three years. I ran a month of failure / recovery scenarios (pull power while writing, pull data cable while writing, etc, with single, raid1, dup). In all cases, I was able to recover without loss of data or data corruption.

          I've run into two cases of silent ext4 corruption in the same time frame, with SATA controllers or the on-drive controller failing silently, writing crap to backup drives. I convert the suspect drive to btrfs, and btrfs immediately reports CRC corruption. Once you live through a couple of those, you can't use a filesystem that doesn't CRC data and metadata anymore.
          Last edited by macemoneta; 22 August 2015, 02:47 PM. Reason: Typo

          Comment


          • #6
            Why was the power save governor used for the tests? 

            Comment


            • #7
              Originally posted by toyotabedzrock View Post
              Why was the power save governor used for the tests? 
              And why is it that I always end up with odd character references after my posts?
              ?
              And if I add a newline I get the above characters.
               

              Comment


              • #8
                What I get from this is that f2fs is a viable alternative to ext4

                Comment


                • #9
                  I've had problems before with btrfs, mostly when using subvolumes and raid. I did manage to recover the one time I had a problem with raid, though, because it was raid1.

                  I'll stick with ext4 until btrfs gets more stable raid support, methinks.

                  Comment


                  • #10
                    Originally posted by macemoneta View Post
                    I'd rather stick to btrfs; I've had too many silent corruptions with ext4.
                    Never had any silent corruption with ext4. But I had a good many very verbose with btrfs, loosing terrabytes of filesystems.
                    I do tripped bugs in ext4 combined in container local high memory pressure. But those bugs lead to blocking file system acces. Nothing more.
                    I lost terrabytes of data with btrfs on a backup server again and again and again.
                    In the end I use ext4 as trustworthy frontend, and btrfs as a unreliable backup. Because ext4 can't beat btrfs when it comes to snapshot/delete. It takes a second to snapshot, and deletes of a snapshotted tree what takes ext4 26 hours is a few minutes on btrfs.
                    Another point against btrfs is the insane amount of memory it uses.
                    But in the end I hope btrfs will be as trustworthy as ext4 or even as much as reiserfs in the 2.4 kernel series, because btrfs has this insane amount of checking that I really want. Especially in a SOHO environment where my photographs are going on my personal cloud.
                    Actually, btrfs should become cloud based... My current attempts will be using an fcoe exported physical volume from another server, together with a local disk. But what if btrfs was running locally *and* remotely, working together for raid 1 storage on non raid disk configurations. The current btrfs implementation should allow something like that with not too much work. I mean: currently raid one is implemented by taking 2 "lower level" individual btree storages and make sure they have the same higher level data in that storage.

                    Comment

                    Working...
                    X