Announcement

Collapse
No announcement yet.

Btrfs Gets Fixes & Low-Level Improvements With Linux 4.19

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

  • Btrfs Gets Fixes & Low-Level Improvements With Linux 4.19

    Phoronix: Btrfs Gets Fixes & Low-Level Improvements With Linux 4.19

    David Sterba of Facebook sent in the Btrfs file-system updates today for the Linux 4.19 kernel merge window...

    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
    one of the most common critique to btrfs was that the code base was a mess. I'm happy to see that developers are working hard to fix it before adding new features. Btrfs is working great for what I'm concerned.

    Comment


    • #3
      Sounds like a lot of nice new features this time :-) I use btrfs on all my systems, especially Raid 1 on multiple disks with different sizes is great.
      Last edited by R41N3R; 13 August 2018, 04:33 PM.

      Comment


      • #4
        nice!

        Comment


        • #5
          I use Btrfs with satisfaction on my PCs with openSUSE, happy with the improvements!

          Comment


          • #6
            does btrfs work well with raw or qemu images now?
            i use them very frequently and btrfs fragmented them that much that i really hurt the vm performance.
            i'd like to switch back though

            Comment


            • #7
              Originally posted by flower View Post
              does btrfs work well with raw or qemu images now?
              i use them very frequently and btrfs fragmented them that much that i really hurt the vm performance.
              i'd like to switch back though
              Don't switch back. For me BTRFS is the filesystem of choice, but performance on BTRFS for files that are constantly updated is not good.

              If you still would like to try (qcow image) you can try out this:
              run chattr +C /var/lib/libvirt/images or wherever you store them which will turn off BTRFS copy-on-write behavior on that directory.
              Keep in mind that this will NOT affect existing files, which should be recreated (copy them). You might also want to try out different IO options, for example turn OFF caching and let BTRFS deal with that.

              You might also want to isolate your images so you could create a separate subvolume before applying the chattr cmd on it and store your no-cow files in a separate subvolume.

              Even with the copy on write turned off you would still like to defragment your VM images regularly as well, and you definitively want to run a btrfs balance operation every now and then to clean up some allocation blocks.

              Note that turning off nocow disables BTRFS integrity checksums for those files (that subvolume) so if you look away from the ease of management, you just might consider another filesystem for your VM's for now

              http://www.dirtcellar.net

              Comment


              • #8
                Originally posted by flower View Post
                does btrfs work well with raw or qemu images now?
                i use them very frequently and btrfs fragmented them that much that i really hurt the vm performance.
                i'd like to switch back though
                Any CoW filesystem in the world will by definition do that. The way to use disk images on Btrfs is to disable CoW on those files. It can be done from the command line:

                chattr +C disk-image.qcow2

                Caveat: apparently it only works if disk-image.qcow2 is empty (e.g. zero size). If the file already has some contents, it will not accept to switch it to non-cow mode. The easiest solution to this is then to enable the non-cow mode for the whole directory where your disk images are stored (/var/lib/libvirt/images if you are using virt-manager, for example). Once that's done, all files created FROM THAT MOMENT ON in the directory will automatically be non-cow.

                If you already have an existing disk image, you need to enable +C on the directory and then physically copy it so that a new non-cow file is created.

                With cow disabled, disk images work just fine on Btrfs. It won't provide the world's best VM performance but it's largely adequate for desktop VM needs. In practice, non-cow files on Btrfs behave and perform basically similarly to zvols on ZFS. In fact they are actually the same thing, just presented differently to the user.

                Comment


                • #9
                  Originally posted by waxhead View Post


                  Note that turning off nocow disables BTRFS integrity checksums for those files (that subvolume) so if you look away from the ease of management, you just might consider another filesystem for your VM's for now
                  Thank you

                  I just hope it will get better someday. most of my vm's are on lvm-lvs right now. another problem for me as btrfs doesnt like lvm that much (ok, it just dont likes snapshots or lvm-raids)

                  i knew that chattr "trick" but it seems to risky to me - i tend to forget such things.

                  i dont like to defrag ssd's. back then i solved it by moving the whole raw image to backup and restore it immediatly from there.

                  i'll stay on lvm/ext4 for the time being

                  Comment


                  • #10
                    Originally posted by jacob View Post

                    With cow disabled, disk images work just fine on Btrfs. It won't provide the world's best VM performance but it's largely adequate for desktop VM needs. In practice, non-cow files on Btrfs behave and perform basically similarly to zvols on ZFS. In fact they are actually the same thing, just presented differently to the user.
                    i've read that zfs deals much better with vm-images than btrfs so i believe there is some potential for btrfs too.
                    but yes you are right that cow and many-small-writes-to-one-file does not go well together.

                    Comment

                    Working...
                    X