Announcement

Collapse
No announcement yet.

Linux 5.14 SSD Benchmarks With Btrfs vs. EXT4 vs. F2FS vs. XFS

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

  • #71
    Originally posted by gadnet View Post

    what's the use of btrfs if you disable snapshots and checksumming, use xfs/ext4 then
    it would be better to test all FS with also ZFS , with noatime and in a raid 1 config as you allways want to have at least raid1 security and who run atime in a cow file system ?

    best regards.
    You still get snapshots and all the other things with btrfs. Even reflinks works with nodatacow.

    ​​​

    Comment


    • #72
      Originally posted by S.Pam View Post

      You still get snapshots and all the other things with btrfs. Even reflinks works with nodatacow.

      ​​​
      well, it prevent checksum and snapshot reactivate datacow so no if you want nodatacow you have no snapshot and no checksum at all.

      Can copy-on-write be turned off for data blocks?


      Yes, there are several ways how to do that.

      Disable it by mounting with nodatacow. This implies nodatasum as well. COW may still happen if a snapshot is taken. However COW will still be maintained for existing files, because the COW status can be modified only for empty or newly created files.

      Comment


      • #73
        Originally posted by sandy8925 View Post
        So .......btrfs on hard drive for home/personal server use cases should be fine right?
        Some distros actually use it as the default filesystem. I think OpenSUSE is one.

        I've used it at home & work for 6+ years, mostly without issue. The only time I had issues was with a SSD that was failing its long self-test (accessed via smartctl). Since it was a single-drive install, there was nothing BTRFS could really do, other than report the corruption during btrfs check.

        Comment


        • #74
          Originally posted by coder View Post
          Some distros actually use it as the default filesystem. I think OpenSUSE is one.

          I've used it at home & work for 6+ years, mostly without issue. The only time I had issues was with a SSD that was failing its long self-test (accessed via smartctl). Since it was a single-drive install, there was nothing BTRFS could really do, other than report the corruption during btrfs check.
          Right, but performance is also really important for me, and based on these benchmarks, it looks like performance falls short by a huge amount.

          This is with regards to SSD. I don't feel confident in using it for the daily driver for example.

          Comment


          • #75
            Originally posted by sandy8925 View Post
            Right, but performance is also really important for me, and based on these benchmarks, it looks like performance falls short by a huge amount.
            Suit yourself. I think these are mostly corner cases, however. If Michael had posted more standard workloads, like kernel compilation and file decompression, you probably wouldn't see much difference between any of the options.

            It's just a matter of priorities. If you don't prioritize BTRFS' features above performance, then I think you have your answer!

            Comment


            • #76
              Originally posted by sandy8925 View Post

              Right, but performance is also really important for me, and based on these benchmarks, it looks like performance falls short by a huge amount.

              This is with regards to SSD. I don't feel confident in using it for the daily driver for example.
              So what apps are going to use SQLite in your daily use? And you can easily override COW for those specific databases anyway. I've done that for Firefox, and that's basically the only app I have.
              Last edited by curfew; 31 August 2021, 04:13 AM.

              Comment


              • #77
                Originally posted by curfew View Post
                So what apps are going to use SQLite in your daily use? And you can easily override COW for those specific databases anyway. I've done that for Firefox, and that's basically the only app I have.
                Lots of apps use Sqlite for local data storage. And no, going around and overriding COW for each specific database is extra work that I don't want to take on.

                It's clear that Btrfs isn't suitable as a general purpose system when it is ridiculously slower than everything else.

                Comment


                • #78
                  Originally posted by darkbasic View Post

                  That's an half-truth: if you do snapshots frequently you're basically doing COW anyway, thus losing most of the performance benefits.
                  Well, you can do snapshots during the night hours and weekends, when nobody is working. Just like backups.

                  Also, correct me if I'm wrong, but while theoretically the nodatacow files should not get deduplicated during snapshot, practically files that deserve "nodatacow" should be heavily used and pretty much always change between snaps, so there should be no difference in disk space requirements ...

                  Comment


                  • #79
                    Originally posted by sandy8925 View Post

                    Lots of apps use Sqlite for local data storage. And no, going around and overriding COW for each specific database is extra work that I don't want to take on.

                    It's clear that Btrfs isn't suitable as a general purpose system when it is ridiculously slower than everything else.
                    How is it slower? For example Firefox probably doesn't write into the SQLite DB all that much when you're browsing the web. It's going to write once into browser history and maybe cache a favicon for a new website. You are being a ridiculous idiot if you claim that the underlying FS has any effect on performance with this kind of usage. That's why synthetic performance benchmarks are useless crap and this "article" is a god damn joke.

                    Comment


                    • #80
                      Originally posted by S.Pam View Post
                      As far as I know, most databases do not contain duplicate data to be able to repair itself.
                      cow is a defence against power loss during incomplete write. though nodatacow also disables checksum, but we are benchmarking against ext4 which doesn't have checksum either(and updating checksum takes time btw, i.e. negatively affects benchmark results)
                      Originally posted by S.Pam View Post
                      What if you run guests without support for advanced filesystems?
                      then it will fare no worse than on bare metal
                      Originally posted by S.Pam View Post
                      IMHO Btrfs provides a sysadmin a really strong simple way to guarantee integrity, manageability and performance (recovery-time), which previously was very hard to achieve across the board.
                      argree

                      Comment

                      Working...
                      X