Announcement

Collapse
No announcement yet.

Ubuntu 12.10 File-Systems: Btrfs, EXT4, XFS

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

  • Ubuntu 12.10 File-Systems: Btrfs, EXT4, XFS

    Phoronix: Ubuntu 12.10 File-Systems: Btrfs, EXT4, XFS

    For those curious about the file-system performance of Ubuntu 12.10, here are some benchmarks from Quantal's Linux 3.5 kernel with the EXT4, XFS, and Btrfs file-systems.

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

  • #2
    Interesting to the btrfs doing very well with threaded I/O does that make it ideal for SSDs?
    Are there stabel fsck tools for btrfs available already?

    Comment


    • #3
      I've always found it hard to choose a FS based on IO and throughput graphs alone. I wish there were an easy way to incorporate CPU utilization, latency, and other factors without having to resort to fancy OLAP/Cubes or pivot tables. I hate to admit this, but a huge number of our enterprise systems still use EXT3 because I am unable to make a case for another FS in a quick and easily demonstrable manner. Those environments that do run EXT4 were only changed after a duplicate environment was created and full perf/regression analysis had been conducted.

      If anyone has an easier way than what is generally accepted as being "the right way", I'm all ears.

      F

      Comment


      • #4
        Not an Ubuntu user, so a small question: Do I have to expect that the Ubuntu kernel will be patched in a way that I can see differences in filesystem performance compared to a stock kernel from kernel.org? If so, wouldn't it make sense to also put the stock kernel into those benchmarks?
        Or is there any other reason to test specifically the Ubuntu kernel and not a stock one, besides having Ubuntu in the title of the article for getting more page-hits from Ubuntu users?

        Comment


        • #5
          Originally posted by blackout23 View Post
          Interesting to the btrfs doing very well with threaded I/O does that make it ideal for SSDs?
          Are there stabel fsck tools for btrfs available already?
          BTRFS has an SSD mount option which changes some of the underlying logic. To date, I have not seen a compelling set of benchmark results to call it faster than without the mount option on an SSD.

          There are tools for BTRFS, including fsck. I do not know that I would call them stable (It's a relative term), nor do I believe that fsck is as essential as it was with the previous generation of filesystems.

          F

          Comment


          • #6
            Originally posted by russofris View Post
            BTRFS has an SSD mount option which changes some of the underlying logic. To date, I have not seen a compelling set of benchmark results to call it faster than without the mount option on an SSD.

            There are tools for BTRFS, including fsck. I do not know that I would call them stable (It's a relative term), nor do I believe that fsck is as essential as it was with the previous generation of filesystems.

            F
            Wasn't the btrfs fsck incompatible with the other ones (ext4 etc) ??

            Comment


            • #7
              Originally posted by 89c51 View Post
              Wasn't the btrfs fsck incompatible with the other ones (ext4 etc) ??
              Yes. BTRFS and EXT4 are two different file system with completely different architectures, so this is expected.

              F

              Comment


              • #8
                Originally posted by TobiSGD View Post
                Not an Ubuntu user, so a small question: Do I have to expect that the Ubuntu kernel will be patched in a way that I can see differences in filesystem performance compared to a stock kernel from kernel.org? If so, wouldn't it make sense to also put the stock kernel into those benchmarks?
                Or is there any other reason to test specifically the Ubuntu kernel and not a stock one, besides having Ubuntu in the title of the article for getting more page-hits from Ubuntu users?
                I do not believe that there will be performance impacting differences (you could look at the diffs). Regarding performance, I would recommend that you double check the BTRFS mount options during the installation of Ubuntu, as the defaults are pretty tame, and may not be the most suitable for your installation.

                F

                Comment


                • #9
                  Originally posted by russofris View Post
                  Yes. BTRFS and EXT4 are two different file system with completely different architectures, so this is expected.

                  F
                  Yes of course thats true but i remember reading that it couldn't be used as the other ones hence you cant just fsck as with an ext4 for example.

                  Comment


                  • #10
                    between the COW and the online checking, there is less need for fsck on btrfs compared to ext3/4. The is a btrfsck since a few months ago:
                    https://btrfs.wiki.kernel.org/index.php/Btrfsck
                    and also
                    https://btrfs.wiki.kernel.org/index.php/Restore
                    If you do hit file system errors it is worth getting on the btrfs irc channel. they can help figure out if you have actually hit a bug in btrfs.

                    @russofris
                    for ext4 you could argue based on features. the main ones being less fragmentation, faster fsck, and more recently metadata checksums https://ext4.wiki.kernel.org/index.p...data_Checksums http://kernelnewbies.org/Linux_3.5#h...a7b417333147f8

                    for btrfs you could argue that full checksumming makes the data much more safe. with traditional raid1 if a block differs between the 2 drives you only know that something is wrong (and you only notice when scrubbing), with brtfs 'raid1' you can see which version of the block has the right checksum and you can spot corruption without having to scrub.
                    but the counter argument is that much newer code makes it very unsafe. i am sure some people wont consider btrfs safe until they know it has been in wide spread use for 5 years.

                    Comment


                    • #11
                      Originally posted by ssam View Post
                      @russofris
                      for ext4 you could argue based on features. the main ones being less fragmentation, faster fsck, and more recently metadata checksums
                      Indeed. Unfortunately, I am still stuck with the perf/regression testing, and still have to write a CBA report for the directors. The other option is to wait for our vendor (RHEL or OEL) to adopt the new FS as a default/recommended option and implement it during the next cycle. To give you an example of what enterprise admins are up against, it took me almost 4 years and over 2 million dollars to migrate end-to-end from 1024 to 2048bit SSL. The meeting minutes from the project are available for your viewing.


                      F

                      Comment


                      • #12
                        Any reason to stop at 2k and not go to 4k?

                        Comment


                        • #13
                          Originally posted by curaga View Post
                          Any reason to stop at 2k and not go to 4k?
                          A number of third party external interfaces are based upon custom SSL implementations (probably derived from extremely old OpenSSL) and do not support 4k certs. In addition, a number of handsets (we work with mobile devices) released prior to 2009 have no support for 4096bit, nor do they have an automated manner in which to update their truststores (Verisign's Class3 G5 2048bit migration was a major PITA). Mobile devices from the 2005-2007 era with 4096bit capabilities often suffer performance regressions with the the larger keys.

                          The low-end Andriod phones (the ones where the carriers do not update the OS, ever) are a plague on the IT industry. We're going to enter into an era of cellular botnets and malware infested devices soon. This isn't Android's fault, rather the result of carriers/manufacturers' hasty TTM and nonexistent life cycle planning. It isn't that the carrier "won't" update these devices, it's that they "can't".

                          The iPhone was a godsend. Not because it's better, but because "at least I know what to expect, and can still get someone to make retroactive fixes".

                          Sorry for the off-topic derailment of this thread.

                          F

                          Comment


                          • #14
                            Originally posted by 89c51 View Post
                            Wasn't the btrfs fsck incompatible with the other ones (ext4 etc) ??
                            Despite users just calling "fsck" fsck is actually a wrapper that checks what filesystem you are running it against it, and then re-calls the appropriate fsck program --> fsck.ext4, fsck.xfs, fsck.resierfs etc. Every filesystem needs its own custom fsck (except maybe ext2 and 3 can use eachothers. but ext4 probably needs its own after all its new features), the only common link is the name and thats just for consistency.


                            Ontopic: Im glad to see BTRFS maturing, and gaining speeds. its not as fast as ext4 but I definitely think that its usable in a desktop environment now without too much of a penalty, the only thing that bothers me is the possibility for large fragmentations and the fact that discard isnt enabled by default despite BTRFS detecting if its on an SSD automatically. I have an SSD so the fact discard isnt automatic is a bit of an annoyance, though admittedly fragmentation isnt as big of a deal to me since read's are all 1 universal speed unlike with traditional drives. I just always liked the fact that ext4 was good enough to not need a defragmentor most of the time.

                            Side note: Why is Btrfs so good at threaded IO? Like what the f*ck? Thats a huge jump up from ext4 and xfs. Is it because of BTRFS design or what?

                            Comment


                            • #15
                              Originally posted by Ericg View Post
                              Side note: Why is Btrfs so good at threaded IO? Like what the f*ck? Thats a huge jump up from ext4 and xfs. Is it because of BTRFS design or what?
                              My guess (when I see strange results like that) is that BTRFS is ignoring an fsync or flush of some type, and caching when it shouldn't be. I would be both surprised and pleased if this is not the case.

                              F

                              Comment

                              Working...
                              X