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.

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

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

    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


                    • #11
                      Originally posted by kebabbert View Post
                      Why this focus on speed? Why not focus on data safety?
                      Reliability should be a given for a filesystem.

                      Comment


                      • #12
                        Originally posted by stan View Post
                        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.
                        Now this is a VERY good argument to use EXT4 over BTRFS! Why does no one say this except Stan?

                        Heck, I can make an unsafe fast solution that no one can trust. The difficulty is making it stable and safe - and yes, that will become a bit slower but some might consider that worth the price. If what Stan says is true, then everybody should prefer EXT4 over BTRFS?

                        Comment


                        • #13
                          ... However

                          (@kebabbert)

                          ... Because btrfs is far too immature to actually live up to the its potential reliability benefits.

                          Sure, I'd love to have ZFS-like-features on Linux, but for now, ext4 is more reliable than btrfs.
                          DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                          SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                          BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                          LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                          Comment


                          • #14
                            not sure

                            I'm not sure the 'inode_cache' option has been tested the right way, and the article doesn't describe in detail how this was done.

                            This option does some FS modifications on first boot, so in order to test, it is probably best to boot once with this option in effect, do some work, reboot, and only then run the tests.

                            Comment


                            • #15
                              Originally posted by DanL View Post
                              Reliability should be a given for a filesystem.
                              Well, fact is, that reliability is not given for any filesystem. Apparently, there are many reports of BTRFS corrupting data. Here is one of the reports from last month:
                              http://phoronix.com/forums/showthrea...731#post249731

                              Comment

                              Working...
                              X