Announcement

Collapse
No announcement yet.

Btrfs Gets Big Changes, Features In Linux 3.14 Kernel

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

  • #46
    Originally posted by jwilliams View Post
    Do you have any clue at all? Did you even look at the CPU in the benchmark? And you accuse me of not reading.
    You're just spewing nonsense now. Of course i saw the CPU. A 4770 is pretty fast, but it's not that crazy. And of course, i was looking at just the single-threaded performance, just to make things fair. The numbers skyrocket if you add multi-threading.

    So does this go back to your phone argument or what?

    How about this - can you give me a straight up scenario in which you think this makes a major difference to someone? An actual real-world scenario, not just you saying "look at the benchmark numbers".

    Most filesystems don't even have built-in compression, and btrfs already has a pretty good implementation. Why do you think the current one is so deficient that an upgrade to it will result in huge user improvements? Personally, i'm glad he's still focusing on things like crashes and infinite loops, because that seems a heck of a lot more important to me.

    Comment


    • #47
      Originally posted by Akka View Post
      I think I have seen somewhere that Jolla use btrfs
      Hmm, interesting. I can't seem to find anything official, but there do seem to be some comments out there that Jolla is using btrfs.

      I could see how lz4 might be interesting for them.

      The good news is, it should be extremely easy for them to implement it if they think it will help their product. And since they are just starting out in a highly competitive market, they can use every little advantage they can find. Seems like an easy win for them - unless of course they determine that it doesn't really make a difference in average phone usage. In which case they probably won't bother, but nobody will be missing it anyway.

      Comment


      • #48
        Originally posted by mercutio View Post
        Code:
        the difference isn't minor, as a general idea, here's fsbench on a i7-4770 cpu with 1 thread:
         # ./fsbench -b8192 -t1 lz4 zlib lzo /src/text/dickens 
        Codec                                   version      args
        C.Size      (C.Ratio)        E.Speed   D.Speed      E.Eff. D.Eff.
        LZ4                                     r97          
            7282840 (x 1.400)      363 MB/s 1859 MB/s       103e6  105e6
        zlib                                    1.2.8        6
            4670489 (x 2.182)     34.0 MB/s  219 MB/s        18e6   19e6
        LZO                                     2.06         1x1
            6969959 (x 1.462)      329 MB/s  468 MB/s       104e6  100e6
        Codec                                   version      args
        C.Size      (C.Ratio)        E.Speed   D.Speed      E.Eff. D.Eff.
        done... (4*X*1) iteration(s)).
        
        and with 8 threads:
        # ./fsbench -b8192 -t8 lz4 zlib lzo /src/text/dickens  
        Codec                                   version      args
        C.Size      (C.Ratio)        E.Speed   D.Speed      E.Eff. D.Eff.
        LZ4                                     r97          
            7282840 (x 1.400)     1979 MB/s 7951 MB/s       564e6  566e6
        zlib                                    1.2.8        6
            4670489 (x 2.182)      164 MB/s 1159 MB/s        89e6   94e6
        LZO                                     2.06         1x1
            6969959 (x 1.462)     1848 MB/s 2483 MB/s       584e6  588e6
        Codec                                   version      args
        C.Size      (C.Ratio)        E.Speed   D.Speed      E.Eff. D.Eff.
        done... (4*X*1) iteration(s)).
        it's quite obvious from those numbers, that decompression speed with lzo on a single thread is slower than a ssd, and lz4 is significantly faster than a ssd. and on older cpus the same should hold true too. i used 8k block size because that's more akin to what file systems use, and is the standard block size of ssd's these days. i have no idea what file systems are doing for matching to block sizes of hard-disks/ssds/raid arrays when using compression atm. they may not be ideal still.
        What percentage of data on your system is an uncompressed book? I'm not taking any sides, I have no idea if it is or not worthwhile, but this benchmark is not that usefull.
        Do we have boot times? boot time of a virtual machine stored on a btrfs fs? time to backup a system disk? a user data disk, with steam games (maybe compressible) and video/pictures (incompressible)? Compilation times without cache, or time to clone/update a big git repo?

        I don't doubt that LZ4 is faster, the question is, is it the bottleneck, and what gains can we expect in real life.

        Comment


        • #49
          Originally posted by erendorn View Post
          What percentage of data on your system is an uncompressed book? I'm not taking any sides, I have no idea if it is or not worthwhile, but this benchmark is not that usefull.
          Do we have boot times? boot time of a virtual machine stored on a btrfs fs? time to backup a system disk? a user data disk, with steam games (maybe compressible) and video/pictures (incompressible)? Compilation times without cache, or time to clone/update a big git repo?

          I don't doubt that LZ4 is faster, the question is, is it the bottleneck, and what gains can we expect in real life.
          Yes, that was always part of my implied argument - that compressed fs have their place but don't provide anything like the boost in general usage that contrived benchmarks would seem to imply. Thanks for expressing it more clearly.

          I do think executable files might show a bit of a boost for booting/app startup, but obviously it's not going to be to the degree shown here.
          Last edited by smitty3268; 02-01-2014, 05:46 AM.

          Comment


          • #50
            Originally posted by smitty3268 View Post
            Yes, that was always part of my implied argument - that compressed fs have their place but don't provide anything like the boost in general usage that contrived benchmarks would seem to imply. Thanks for expressing it more clearly.

            I do think executable files might show a bit of a boost for booting/app startup, but obviously it's not going to be to the degree shown here.
            And actually, as a btrfs+lzo user, I'm genuinely interested in these numbers

            Comment


            • #51
              Originally posted by mercutio View Post
              true, i'd like to see 3 disk raid 10 support, but i haven't seen any work started on that. and i think lz4 support would benefit more users. i'd ilke to see btrfs with lz4 compression start appearing on cellphones for instance.
              Jolla phone uses BTRFS, not sure which compression though.

              Comment


              • #52
                Originally posted by erendorn View Post
                What percentage of data on your system is an uncompressed book? I'm not taking any sides, I have no idea if it is or not worthwhile, but this benchmark is not that usefull.
                Do we have boot times? boot time of a virtual machine stored on a btrfs fs? time to backup a system disk? a user data disk, with steam games (maybe compressible) and video/pictures (incompressible)? Compilation times without cache, or time to clone/update a big git repo?

                I don't doubt that LZ4 is faster, the question is, is it the bottleneck, and what gains can we expect in real life.
                i did it with /usr/bin/clang too much was my biggest executable in /usr/bin and clang gave better compression. we don't have any real times, because btrfs isn't in mainline kernel yet and grub doesn't support it yet.

                compilation times seem to be close enough to not care about between different filesystems. (ext4, btrfs with lzo compression, zfs with lz4 compression)

                boot times don't really matter too. what seems to matter, is how much it slows your system down when doing lots of io, where btrfs either has bugs or compression overheads.
                Last edited by mercutio; 02-01-2014, 04:19 PM.

                Comment


                • #53
                  Originally posted by mercutio View Post
                  we don't have any real times, because btrfs isn't in mainline kernel yet and grub doesn't support it yet.
                  Uh, what?

                  Comment


                  • #54
                    Originally posted by GreatEmerald View Post
                    Uh, what?
                    err btrfs with lz4 i meant.

                    Comment


                    • #55
                      Originally posted by Prescience500 View Post
                      Is there or will there be an effort to make ensure that BTRFS is as fast as or faster than EXT4? I know BTRFS is all about features rather than performance, but the average home user doesn't need all of those advanced features. For me, faster makes a less painful time redoing my operating system and transfering all of my files every 6 months.
                      This perspective is coming from someone using ZFS but all of the features of these file systems are definitely applicable to home users. (I'm pretty sure btrfs has most of these same features but syntax is different)

                      On disk compression results in improved performance and less space used.

                      Snapshots mean you could snapshot your system before you let your mom on the computer and after she pollutes your browser history with pinterest, aol email and browser toolbars, you could restore back to the snapshot.

                      You can also use snapshots to restore computer after a hardware failure. I needed to rebuild the zfs pool on my desktop a while back to switch drive layout and to back it up I did a zfs send/recv to my nas, rebuilt the pool and then zfs send/recv back to the desktop to restore my exact system.

                      Then checksums ensures that everything is perfectly preserved. In some cases it can give you an early warning that a drive is dying and in others, it can prevent movies/pictures of loved ones from corrupting.

                      Then, folder mount points on ZFS also make for extremely easy migration from distro to distro. As an example of this, You can install a secondary OS alongside another and switch from one to the other while maintaining all files from the old install without juggling partitions. Just leave entire drive as ZFS:

                      zfs create pool/OS -o mountpoint=none
                      zfs create pool/OS/Arch -o mountpoint=/
                      zfs set mountpoint=/pool pool
                      zpool set bootfs=pool/OS/Arch pool

                      Then lets say you didn't like arch and wanted to use gentoo instead. All you would have to do is:

                      zfs set mountpoint=/backup pool/OS/Arch
                      zfs create pool/OS/Gentoo -o mountpoint=/
                      zpool set bootfs=pool/OS/Gentoo pool

                      This would switch your install to Gentoo while keeping your entire arch install intact. You could switch back if needed or copy the needed files over and then delete it. You could also do this with your home directory to just directly mount your arch home directory into your gentoo install in the exact same spot without needing to copy files over.

                      Also, in regards to your performance concern, a ZFS raid on more than 2 disks (e.g. a raid 5,6,10) outperforms ext4 + mdadm in virtually all cases, zfs also outperforms ext4 + mdadm on a raid 1/0 in multiuser configs (like a server serving files to 5+ clients at once). And that is in just a basic, no frills configuration. With ZFS, you can turn on compression and add SSD caches to make that even faster.

                      Comment

                      Working...
                      X