Announcement

Collapse
No announcement yet.

Btrfs Gets Big Changes, Features In Linux 3.14 Kernel

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

  • Btrfs Gets Big Changes, Features In Linux 3.14 Kernel

    Phoronix: Btrfs Gets Big Changes, Features In Linux 3.14 Kernel

    While the EXT4 changes and XFS alterations for the Linux 3.14 kernel weren't too exciting, the Btrfs file-system update was submitted today for Linux 3.14 and it's definitely exciting...

    http://www.phoronix.com/vr.php?view=MTU4ODA

  • PinkyThePig
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • GreatEmerald
    replied
    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?

    Leave a comment:


  • mercutio
    replied
    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, 05:19 PM.

    Leave a comment:


  • Vistaus
    replied
    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.

    Leave a comment:


  • erendorn
    replied
    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

    Leave a comment:


  • smitty3268
    replied
    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, 06:46 AM.

    Leave a comment:


  • erendorn
    replied
    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.

    Leave a comment:


  • smitty3268
    replied
    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.

    Leave a comment:

Working...
X