Announcement

Collapse
No announcement yet.

Btrfs Gets New Features In Linux 3.7

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

  • Btrfs Gets New Features In Linux 3.7

    Phoronix: Btrfs Gets New Features In Linux 3.7

    Chris Mason sent in a large Btrfs file-system pull request for the Linux 3.7 kernel...

    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
    I'm guessing that hole punching leads to better compression, faster file copying and improve performance on ssd with trim support?

    Comment


    • #3
      Originally posted by AJenbo View Post
      I'm guessing that hole punching leads to better compression
      No, not really.

      , faster file copying
      No.

      and improve performance on ssd with trim support?
      In some limited circumstances, maybe.

      The major use case is more efficient space utilization when hosting sparse VM images.

      Comment


      • #4
        turbo charge fsync patch is by Josef Bacik

        Hi Michael,

        the see subject.

        Thanks,
        Martin

        Comment


        • #5
          I wonder if the fsync patch will help with VM performance. Honestly the only things keeping me from using Btrfs as my main FS are 2 things:

          1) I really don't understand how defragmentation works with Btrfs, with EXT4 I just forget about it, but I know that with Btrfs, because of COW, defragging will be important. And running the defrag command on the root directory will only defrag metadata not the contents (source: https://btrfs.wiki.kernel.org/index....doesn.27t_work) and running:

          Code:
          find -xdev -type f -exec btrfs fi defrag '{}' \;
          seems really excessive


          2) I do run VM's sometimes and from what I've heard and seen...Btrfs TANKS with VM's cuz its a lot of small writes.
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #6
            Originally posted by AJenbo View Post
            I'm guessing that hole punching leads to better compression, faster file copying and improve performance on ssd with trim support?
            Hole punching is a (very simple) compression method; it marks certain parts of a file as "unused", so that the filesystem knows that those parts don't have to be stored.

            It represents the location of a file on the physical somewhat like this:
            • part 1 of the file: list of used disk sectors
            • part 2 of the file: marked as unused (this is the "hole" punched into the file)
            • part 3 of the file: list of used disk sectors


            I'm not sure if file copying will be faster when using it (and it might depend on the software doing the copy supporting it), but theoretically it could be faster, especially if both source & destination filesystem support it.

            Comment


            • #7
              ZFS on Linux

              Since you're in for a big FS test which does even include Reiser4, please don't forget ZoL (ZFS on Linux).

              Comment


              • #8
                Originally posted by rvalles View Post
                Since you're in for a big FS test which does even include Reiser4, please don't forget ZoL (ZFS on Linux).
                ZFSOnLinux has some nice performance improvements of its own being developed that could be in the next release.

                Comment


                • #9
                  Experience?

                  Any voices from users to the real performance and functionality gains? Expectations are only sorts of wrap...

                  Comment


                  • #10
                    Originally posted by pjezek View Post
                    Any voices from users to the real performance and functionality gains? Expectations are only sorts of wrap...
                    I am only aware of the following:

                    Currently, the size of read and write requests on vdevs is aligned according to the vdev's ashift, allocating a new ZIO buffer and padding if need be. This makes sense for write requests to prevent...

                    Comment

                    Working...
                    X