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


    • #72
      Originally posted by sandy8925
      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


      • #73
        Originally posted by sandy8925
        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


        • #74
          Originally posted by sandy8925

          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


          • #75
            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


            • #76
              Originally posted by sandy8925

              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


              • #77
                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


                • #78
                  Originally posted by F.Ultra View Post
                  Only if enabled though and AFAIK both MySQL/MariaDB and PostgreSQL have it disabled as default.
                  https://en.wikipedia.org/wiki/ACID#Atomicity (context was cow)
                  Last edited by pal666; 31 August 2021, 04:51 PM.

                  Comment


                  • #79
                    Originally posted by sandy8925
                    So .......btrfs on hard drive for home/personal server use cases should be fine right?
                    i use btrfs on harddrives for many years.

                    Comment


                    • #80
                      Originally posted by gadnet View Post
                      what's the use of btrfs if you disable snapshots and checksumming, use xfs/ext4 then
                      nodatacow doesn't disable snapshots. you only disable it for database files because they do cow themselves. most of your files are not databases and btrfs is reasonably fast with them
                      Last edited by pal666; 03 September 2021, 08:59 PM.

                      Comment

                      Working...
                      X