Announcement

Collapse
No announcement yet.

Testing Out The Btrfs Mount Options On Linux 3.2

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

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

    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
    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:




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

    Comment


    • #3
      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).

      Comment


      • #4
        Snappy

        What about with Google's compression algorithm Snappy?

        Comment


        • #5
          lz4

          Imagine this with with lz4...

          Comment


          • #6
            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.

            Comment


            • #7
              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?

              Comment


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

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    BTRFS worse than EXT4 for both speed and reliability

                    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.

                    Comment

                    Working...
                    X