Announcement

Collapse
No announcement yet.

Btrfs Seeing Some Nice Performance Improvements For Linux 5.9

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

  • #21
    Hot data tracking/balancing is already considered

    Comment


    • #22
      Originally posted by starshipeleven View Post
      What distro? Ubuntu is known for btrfs horror stories. I've been following btrfs mailing list and a lot of the people asking for help are from some random Ubuntu LTS using older kernels.

      In other distros like OpenSUSE where btrfs is default filesystem it doesn't blow up like that. Now also on Fedora will become first-class citizen.
      The same happened to me ~5 years ago with Arch Linux, but I still use btrfs because there are no better alternatives.
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #23
        Originally posted by pal666 View Post
        you mean for benchmarking speed of filesystem resize?
        Some of the benchmarks (e.g., sqlite, postgres) use fsync ... The degree to which they are sped up is TBD.

        Comment


        • #24
          This makes me wonder whether I should use ZFS or Btrfs for my next Ubuntu install. I’m leaning towards ZFS because the official support is likely to be stronger.

          Comment


          • #25
            Originally posted by darkbasic View Post
            The same happened to me ~5 years ago with Arch Linux, but I still use btrfs because there are no better alternatives.
            Well, if it didn't happen again it's OK I guess?

            Comment


            • #26
              Originally posted by cynical View Post
              This makes me wonder whether I should use ZFS or Btrfs for my next Ubuntu install. I’m leaning towards ZFS because the official support is likely to be stronger.
              +1 for ZFS, Ubuntu or not.

              Comment


              • #27
                Originally posted by starshipeleven View Post
                What distro? Ubuntu is known for btrfs horror stories. I've been following btrfs mailing list and a lot of the people asking for help are from some random Ubuntu LTS using older kernels.

                In other distros like OpenSUSE where btrfs is default filesystem it doesn't blow up like that. Now also on Fedora will become first-class citizen.
                gentoo.

                Comment


                • #28
                  Originally posted by dev_null View Post
                  Couple of years ago I lost 2TB volume because of btrfs bug. and a tool to fix the fs made everything much worse. Now I do not treat it seriously, at least wont put there what I want to find tomorrow. This never happened with ext4. Probably things enhance with a time, but I’m just scary.
                  I never encountered a situation in which btrfs destroyed my data (but that might be just because I didn't execute the same series of btrfs commands as you).

                  ext4 is, by itself, a single-device filesystem, while btrfs is a multi-device filesystem. For example, if a person buys a new HDD and the computer case has a free slot where to put the new HDD alongside older HDDs then the new device can be seamlessly added to an existing btrfs mountpoint (it takes just several minutes of time (unless the person is doing it the 1st time)). Removing an old device from a btrfs mountpoint is also seamless, assuming the remaining devices have enough capacity to hold the removed device data.

                  From Using_Btrfs_with_Multiple_Devices:

                  Btrfs can add and remove devices online, and freely convert between RAID levels after the FS has been created.
                  I don't understand why ext4 doesn't support compression.

                  The only btrfs issues I am experiencing are:
                  • Longer HDD mount times when booting a machine (about 10 seconds, a multi-terabyte multi-HDD filesystem)
                    • Linux 5.9-git isn't noticeably more efficient than 5.8 in my case
                  • Not very efficient implementation of 'sync --file-system'
                    • btrfs isn't writing cached data to the disk early enough when the disk is otherwise idle

                  Comment


                  • #29
                    I'm going to setup btrfs on my 2TB NVMe and test it under windows (free driver) and linux. Will be interesting, assuming my drive even turns up from China..................

                    Comment


                    • #30
                      Originally posted by waxhead View Post
                      Right now there is not much of a difference, but in the long run this could allow for parity based raid where the stripes are on fast groups of disks and the parity on slower devices. And a disk failure could use a different group as spare space or redundant space. It works also make it easier to isolate metadata on its own controller for example. Plus migrationomigration data would not be across filesystems. It all boils down to flexibility.
                      nothing you listed requires it to be subvolume-specific. i.e. if you could put parity for whole fs on separate drives, it would work just as well(because all good things about subvolumes stem from single fact that they are not tied to partitions. as soon as you tie them, you don't need them)
                      Last edited by pal666; 04 August 2020, 07:47 PM.

                      Comment

                      Working...
                      X