Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: Testing Out The Btrfs Mount Options On Linux 3.2

  1. #1
    Join Date
    Jan 2007
    Posts
    15,618

    Default Testing Out The Btrfs Mount Options On Linux 3.2

    Phoronix: Testing Out The Btrfs Mount Options On Linux 3.2

    Earlier this month I benchmarked all the major Linux file-systems of Ubuntu 12.04: ReiserFS, JFS, EXT2, EXT3, EXT4, Btrfs, and XFS. While Btrfs performed well with Ubuntu 12.04 LTS, it was not always the fastest although it does offer the most advanced feature-set. For those looking to tune a Btrfs file-system for performance, published now are some reference benchmarks showing the Linux Btrfs performance with varying mount options.

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

  2. #2
    Join Date
    Sep 2006
    Posts
    714

    Default

    FYI,

    I do believe that the wiki on the kernel.org page is out of date. This has not been kept up since the kernel.org was compromised.

    The up to date wiki is at:
    http://btrfs.ipv5.de/index.php?title=Getting_started
    http://btrfs.ipv5.de/index.php?title=Mount_options


    Although it does not appear much has changed in terms of mount options.

  3. #3

    Default Zlib and LZO tests are flawed

    The Zlib and LZO compression tests are flawed as the FS-MARK creates empty files which obviously get near perfect compression, of course there are lots of text files on Linux system that will benefit from that but in most cases it won't benefit at all. So it is either write down WHY the LZO/ZLIB are so fast or modify FS-MARK to use some media files that won't get compressed much (or the I/O TESTER as well).

  4. #4
    Join Date
    Dec 2011
    Posts
    2,192

    Default Snappy

    What about with Google's compression algorithm Snappy?

  5. #5
    Join Date
    Dec 2011
    Posts
    2,192

    Default lz4

    Imagine this with with lz4...

  6. #6
    Join Date
    Jul 2007
    Posts
    264

    Default

    Quote Originally Posted by BenderRodriguez View Post
    The Zlib and LZO compression tests are flawed as the FS-MARK creates empty files which obviously get near perfect compression, of course there are lots of text files on Linux system that will benefit from that but in most cases it won't benefit at all. So it is either write down WHY the LZO/ZLIB are so fast or modify FS-MARK to use some media files that won't get compressed much (or the I/O TESTER as well).
    This. Compressing a bunch of 0s is a pretty easy task, fs-mark is mis-representative in this case.

  7. #7
    Join Date
    Mar 2009
    Posts
    130

    Question iozone not including fsync in calc times

    When running an Iozone write test, Zlib and LZO compression led to significantly higher results, albeit it was using compression and mostly came down to being run in the system memory at speeds not sustainable by the SATA SSD.
    Michael, would you consider adding the '-e' option to the iozone test definition for pts so fsync is forced and included in calculation times?

  8. #8
    Join Date
    Oct 2007
    Posts
    1,322

    Default

    Someone wake me when btrfs is faster than ext4 and actually compelling to desktop users.

  9. #9
    Join Date
    Nov 2008
    Posts
    418

    Default

    Quote Originally Posted by DanL View Post
    Someone wake me when btrfs is faster than ext4 and actually compelling to desktop users.
    I dont get it. Why this focus on speed? Why not focus on data safety? What do you prefer, fast and corrupted data or slower and correct data? If you never do any checks, it will be fast. Checksumming takes long time, but guarantees data is correct. I rather use slower and correct data, than fast and corrupted data.

  10. #10
    Join Date
    Jan 2008
    Posts
    145

    Default BTRFS worse than EXT4 for both speed and reliability

    Quote Originally Posted by kebabbert View Post
    I dont get it. Why this focus on speed? Why not focus on data safety? What do you prefer, fast and corrupted data or slower and correct data? If you never do any checks, it will be fast. Checksumming takes long time, but guarantees data is correct. I rather use slower and correct data, than fast and corrupted data.
    OK, so let's talk reliability. As it stands, BTRFS is much more prone to corruption and gradual degradation of speed and even available free spance than EXT4. Just look at all the reports of people saying BTRFS becomes unusable after a a few days of running. The fact is that for the vast majority of desktop users, BTRFS still has no advantage over EXT4.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •