Announcement

Collapse
No announcement yet.

Btrfs With Linux 5.14 Has More Performance Tuning, Other Improvements

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

  • Btrfs With Linux 5.14 Has More Performance Tuning, Other Improvements

    Phoronix: Btrfs With Linux 5.14 Has More Performance Tuning, Other Improvements

    With Btrfs continuing to see new adoption by various enterprises, Linux distributions like Fedora Workstation/Cloud and SUSE/openSUSE embracing it, and there continuing to be nice upstream improvements to this file-system driver, Btrfs continues on a nice trajectory in 2021...

    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
    "A sysfs control to limit scrubbing I/O bandwidth per-device"

    I like that. Could use to scrub regularly in the background without putting too much stress on response times.

    Comment


    • #3
      So, how is stability and performance of btrfs these days? I know it used to be shaky, and zfs (used to?) use a lot of memory.

      I'm thinking of repurposing an old computer as a small NAS for home use some time in the not to distant future, so I'm starting to pay more attention to this field. So far I have been sticking to the old reliable ext4 for all my computers, but for a NAS it would be nice to have something like btrfs or zfs which does checksumming.

      Comment


      • #4
        Originally posted by Vorpal View Post
        So, how is stability and performance of btrfs these days? I know it used to be shaky, and zfs (used to?) use a lot of memory.

        I'm thinking of repurposing an old computer as a small NAS for home use some time in the not to distant future, so I'm starting to pay more attention to this field. So far I have been sticking to the old reliable ext4 for all my computers, but for a NAS it would be nice to have something like btrfs or zfs which does checksumming.
        I use Btrfs on all of my personal computers and it runs flawlessly. And I really take advantage of its CoW features with drive snapshots and "rsync --inplace". I would be comfortable in running it on a NAS in a mirrored configuration. But given the choice for that I would choose ZFS. I think that ZFS just has a cleaner and more organized structure, and its encryption feature is awesome. But for ZFS to perform at its best you need to give it lots of memory. Really, I would say that ZFS is better for servers and network storage, and Btrfs is better for desktops. That's what frustrates me about the way that Ubuntu has been handling ZFS so far. They make it available as an install choice for desktops but not for servers. To me that seems completely backwards.

        Comment


        • #5
          Originally posted by Chugworth View Post

          I use Btrfs on all of my personal computers and it runs flawlessly. And I really take advantage of its CoW features with drive snapshots and "rsync --inplace". I would be comfortable in running it on a NAS in a mirrored configuration. But given the choice for that I would choose ZFS. I think that ZFS just has a cleaner and more organized structure, and its encryption feature is awesome. But for ZFS to perform at its best you need to give it lots of memory. Really, I would say that ZFS is better for servers and network storage, and Btrfs is better for desktops. That's what frustrates me about the way that Ubuntu has been handling ZFS so far. They make it available as an install choice for desktops but not for servers. To me that seems completely backwards.
          The way Ubuntu has ZFS setup for their desktop isn't that bad. The problem is their Zsys tool is only used by them so you get locked into Zsys just as much as you get locked into ZFS.

          As far as non-root disks go my primary data disk started as a 2TB ZFS volume 7 years ago, got expanded to a 4TB volume almost a year ago, and became a mirror a few months after that. For networked or additional storage you can't go wrong with either file system but my suggestion is ZFS.

          I'm actually in the process of retiring that 2TB HDD. It's 15 years old and was rocking a Windows 10 install until Sunday. All it has now is Windows games and I'm gonna drawer it once my 4TB HDD for Windows games shows up.

          Anyone else try Win11?

          Comment


          • #6
            Originally posted by Vorpal View Post
            So, how is stability and performance of btrfs these days? I know it used to be shaky, and zfs (used to?) use a lot of memory.

            I'm thinking of repurposing an old computer as a small NAS for home use some time in the not to distant future, so I'm starting to pay more attention to this field. So far I have been sticking to the old reliable ext4 for all my computers, but for a NAS it would be nice to have something like btrfs or zfs which does checksumming.
            They're both pretty good so pick whatever you're comfortable with. My preference is ZFS because there are less layers and it has a more integrated system (like not needing LUKS for encryption).

            My root is BTRFS and my data disks are ZFS. Right tool for the right place

            Comment


            • #7
              Any news regarding the ongoing in-tree zstd syncronisation?

              Comment


              • #8
                Originally posted by Vorpal View Post
                So, how is stability and performance of btrfs these days? I know it used to be shaky, and zfs (used to?) use a lot of memory.

                I'm thinking of repurposing an old computer as a small NAS for home use some time in the not to distant future, so I'm starting to pay more attention to this field. So far I have been sticking to the old reliable ext4 for all my computers, but for a NAS it would be nice to have something like btrfs or zfs which does checksumming.
                Stability on BTRFS is about as good as it gets. Especially if you trace the LTS kernels (like Debian stable does). I used BTRFS on my main computer, as well as my webserver, my fileserver and my "experimental" machine. I also run BTRFS on a older netbook and on a project server (www.se2a1.net) with about 10.6 million files.
                Never had any issues except when trying a "sort of experimental kernel 5.2" in Debian testing. Note that this kernel never hit the Debian STABLE branch for a reason.
                Despite a rather nasty bug in kernel 5.2 I was able to recover all the files I cared about.

                Some advice from me (I have been using BTRFS since before 2013)

                - Partition your drives (BTRFS works on raw devices ,but you will thank me later )
                - Avoid many (more than a 20) subvolumes
                - Run on 64bit architecture (32bit is to the best of my knowledge not as well tested anymore).
                - Do not compress the entire filesystem. Instead use chattr +c on the directory or btrfs property [get/set/list]directory
                - For metadata use RAID1 or if you have enough disks, RAID1c3 or maybe even RAID1c4 if you are paranoid.
                - Use RAID1 or RAID10 on your data (if you have enough space RAID1c3 or RAID1c4 won't hurt anything except performance).
                - NEVER use RAID5/6 for metadata (seriously don't)
                - Avoid using RAID5/6 for data, if you have to it will work , but you *must* run scrub on any unclean shutdown/crash.
                - (not sure if it is implemented, but there was patches for RAID10 to potentially handle more than one disk failure, you may be lucky).
                - Scrub every now and then (figure out what interval best suits your needs).
                - No COW will make BTRFS as "bad" as yet another filesystem (nocow are not checksummed).

                In short - if you use it as a regular filesystem and avoid all the fancy features you should be more than safe. In fact better off than other filesystems.
                If you want to use BTRFS on a single disk you can use DUP metadata, but there is little to no gain except being able to grow the filesystem seamlessly to another disk in the future. I would use XFS or even Ext4 on a single disk system.

                and as with ALL FILESYSTEMS... HAVE RECENT, TESTED, WORKING BACKUPS!!!! Murphy's law never fails to disappoint. (but ironically Murphys law implies that the law itself will fail sometime so you may not need your backups)
                Last edited by waxhead; 29 June 2021, 12:37 PM.

                http://www.dirtcellar.net

                Comment


                • #9
                  Originally posted by Vorpal View Post
                  So, how is stability and performance of btrfs these days? I know it used to be shaky, and zfs (used to?) use a lot of memory.

                  I'm thinking of repurposing an old computer as a small NAS for home use some time in the not to distant future, so I'm starting to pay more attention to this field. So far I have been sticking to the old reliable ext4 for all my computers, but for a NAS it would be nice to have something like btrfs or zfs which does checksumming.
                  We've been using BTRFS for a decade, without a single incident. As long as you understand that some functionality is not yet there, and don't use those functions, it's rock solid.

                  Comment


                  • #10
                    Originally posted by waxhead View Post
                    - Avoid many (more than a 20) subvolumes
                    Do you count snapshots as a subvolume, too? In that case I'd consider that feature as unuseable. 6 subvolumes with like 8 Snapshots each (e.g. the last 8 weeks) is a reasonable usecase.

                    Originally posted by waxhead View Post
                    - Do not compress the entire filesystem. Instead use chattr +c on the directory or btrfs property [get/set/list]directory
                    So it is a difference whether I enable compression via mount option or via chattr? If there is for example a BTRFS partition with one directory in root, lets say "/myData", which contains all of my data which I'd like to have compressed, there are substantially different code pathes involved depending on the method to activate this feature? If true, I'd consider this as a major flaw.

                    Originally posted by waxhead View Post
                    - Scrub every now and then (figure out what interval best suits your needs).
                    To cope with errors of the underlying storage subsystem or to cope with errors caused by BTRFS?


                    Comment

                    Working...
                    X