Announcement

Collapse
No announcement yet.

Btrfs Battles EXT4 With The Linux 2.6.33 Kernel

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

  • Btrfs Battles EXT4 With The Linux 2.6.33 Kernel

    Phoronix: Btrfs Battles EXT4 With The Linux 2.6.33 Kernel

    Earlier this week we published extensive benchmarks of EXT4 that looked at the performance of this Linux file-system under every major kernel release since it was declared stable in the Linux 2.6.28 release. EXT4 has encountered many significant performance losses over time as its developers batten up the data security, but there have been some improvements too. At the same time though the developers working on the still-experimental Btrfs file-system continue to move along and push forward changes with each kernel cycle. Just last month we delivered Btrfs comparative benchmarks using the Linux 2.6.32 kernel, but already out of our own personal interest and requests from readers, we have new tests atop the latest Linux 2.6.33 kernel.

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

  • #2
    A thing about the btrfs compression is that it only compresses if it benefits over all.

    I.g. some times it favours CPU over IO.

    You can see this with text files and video.

    Comment


    • #3
      What sort of data are these benchmarks actually handling? Aren't these benchmarks intended for uncompressed file systems? If it writes files full of zeroes then OBVIOUSLY any compression scheme will perform very well in the benchmark.

      Really, you should do more analysis and less numbers.

      Comment


      • #4
        Originally posted by intgr View Post
        What sort of data are these benchmarks actually handling? Aren't these benchmarks intended for uncompressed file systems? If it writes files full of zeroes then OBVIOUSLY any compression scheme will perform very well in the benchmark.

        Really, you should do more analysis and less numbers.
        They are handling exactly what they say they are handling. Go read about the respective benchmarks if you are interested as they are all documented. fs-mark, dbench, and iozone measure various disk I/O things kind of like bonnie.

        Comment


        • #5
          Originally posted by Smorg View Post
          Go read about the respective benchmarks if you are interested as they are all documented.
          I did try looking this up from their websites, but they don't document this on any of the obvious places I happened to look at.

          I am pretty certain that these FS benchmarks simply write a bunch of zeroes, or some other repeating (and thus well-compressible) pattern, because that's the easiest to generate. Most file systems don't actually care what the data is. If they actually tried to simulate realistic file content, then surely it would be configurable and documented.

          My point is that if you're going to publish any such benchmarks, you should clearly inform readers to take the results with a grain of salt. Testing compressed btrfs with ideally compressible data makes the results completely bogus and there's little point in comparing these results to non-compressible file systems. In practice people use file systems to store data, not zeroes.

          Comment


          • #6
            Reiser4

            Please make a Reiser4 Benchmark test, _PLEASE_.

            I have been looking for FS comparison benchmarks with reiser4 for a long time now. And its hard to find one, which has all the other major filesystems in it, is not outdated, or is not only based on theoretical benchmarks.
            I know Reiser4 is a problematic topic, since its not officially supported by the kernel and because of its unknown future.

            From a technical pov its very interesting though. Because btrfs and r4 have the same design idea, it is interesting too see which fs is doing the better job.
            If I may qoute yourself: "Reiser4 May Go For Mainline Inclusion In 2010". One does not know if this really happens. Linus might be strict on having 2 similar filesystems in the kernel. But there will be discussions about it and therefore benchmarks would be substantial.

            Is very simple to get r4 support into linux. You just need to apply one of these patches.
            The latest stable kernel is not yet supported because of VFS changes. Work is beeing done on this.


            Thanks for all the good work sofar.

            Comment


            • #7
              Originally posted by sektion31
              Because btrfs and r4 have the same design idea, it is interesting too see which fs is doing the better job.
              No, they are quite different. reiser4 is built around normal B+trees with some fancy optimizations and a wandering journal, but fundamentally still a classical journalling file system.

              btrfs on the other hand doesn't have a journal at all and is entirely founded on the idea of copy-on-write B-trees (not to be confused with B+trees), which were invented in 2007 by Ohad Rodeh, years after reiser4 was released and pronounced testing-ready by Namesys.

              The design of upper levels does bear some similarity, but that's because Chris Mason (the creator of btrfs) also worked on reiser4 before.

              Originally posted by sektion31
              Linus might be strict on having 2 similar filesystems in the kernel.
              I don't think that would be an obstacle. So far the reasons for not including reiser4 have been purely technical -- not following conventions, misusing some kernel APIs and duplicating code.
              Last edited by intgr; 01-22-2010, 08:12 AM.

              Comment


              • #8
                Originally posted by intgr View Post
                No, they are quite different.
                oh thanks for clarification. i read that reiser4 and btrfs are more similar to each other than to ext3/4. so i assumed they have a similar design idea.

                So far the reasons for not including reiser4 have been purely technical -- not following conventions, misusing some kernel APIs and duplicating code. I don't think that would be an obstacle.
                good to hear. i think getting into the kernel is reiser4fs only way to stay alive. and i guess thats what the namesys developers think, too. i just hope that development keeps alive, otherwise linus might reject because of no maintainers?

                Comment


                • #9
                  I have a counter request but want to first say "Thanks" for the efforts taken to provide this update on the improvements being made. If not for Phoronix(Michael et al) we would not have much of anything to use to follow the dev work that is quickly & fairly easily understood.

                  The request is to Please do not waste any time with Reiser* fs.
                  For ALL practical purposes, Namesys is as dead as Hans wife: " It has been inactive since late 2007, and as of 2010, is listed with the State of California with a status of "Suspended". "
                  It will never be in the Linux kernel as it is. It *must* have major restructuring to get there. It is incredible how many times this point has been made and yet there are still those that think wishing &|R hoping will make it come true. It will not.
                  I wish it has been forked & fixed to fit with Linux but it was not and ithink it is (much) too late now. Using it for anything like benchmarks just prolongs the agonizing death of the filesystem that almost was.
                  ...

                  JFS & XFS are included in most distro's so, if ext3 is not enough, use them for comparisons.
                  ZFS port via FUSE is active (and supposedly " exceedingly safe to use" ) so it too might be a worthwhile comparison due to the number of functions that both ZFS and btrfs have in common(RAID, snapshots, data compression, ...) as well as their differences.
                  JFS has copy on write function too(XFS does not). Might be interesting to see how good snapshots are handled by all of them. ...

                  But not anything from Namesys, please.

                  Comment


                  • #10
                    Originally posted by fhj52 View Post
                    For ALL practical purposes, Namesys is as dead as Hans wife
                    Who cares about Namesys, reiser4 lives on and is still maintained by some ex-developers in their own time. The obstacles to merging aren't so big that you make them out to be -- they're mostly minor these days; it's just that nobody is making the push for it to go mainline.
                    Originally posted by fhj52 View Post
                    If not for Phoronix(Michael et al) we would not have much of anything to use to follow the dev work that is quickly & fairly easily understood.
                    Fairly? Like using benchmarks that are intended for uncompressed file systems, on a compressed file system?
                    Ironically enough, compressed reiser4 would blow everything else out of the water in these benchmarks.

                    Comment


                    • #11
                      Originally posted by intgr View Post
                      Ironically enough, compressed reiser4 would blow everything else out of the water in these benchmarks.
                      Well I don't know about that, as I've been doing a java port of my companies ide and language and working with a 4.9 GB database (real customer shipping data) it seems here anyways that no matter on SSD or a regular HD but btrfs seems to be edging out r4.

                      Comment


                      • #12
                        Originally posted by intgr View Post
                        [...] compressed reiser4 would blow everything else out of the water in these benchmarks.
                        None of these safer* fs "blow everything else out of the water" ... ext2 would prbly come the closest but who wants to race boats w/o at least a lifejacket so when one gets tossed into the water, at least there's a chance of survival.


                        *safer as in journaled or CoW (or something) to get the data back when errors knock the fs out of whack.

                        Comment


                        • #13
                          Originally posted by deanjo View Post
                          Well I don't know about that, as I've been doing a java port of my companies ide and language and working with a 4.9 GB database (real customer shipping data) it seems here anyways that no matter on SSD or a regular HD but btrfs seems to be edging out r4.
                          I'm not talking about real-world benchmarks, I'm talking about these synthetic benchmarks that Phoronix used in this article, that only write a bunch of zeroes to the disk. They just aren't adequate for benchmarking compressed file systems (reiser4 nor btrfs).

                          Trust me, the one thing reiser4 is really good at is compressing zeroes.
                          Originally posted by fhj52 View Post
                          None of these safer* fs "blow everything else out of the water" ... ext2 would prbly come the closest
                          (Even though you completely missed my point.) You would think so, but most of the time it's not actually true. Modern journaling file systems are much better tuned than old unsafe file systems (ext2, UFS).

                          In fact, for a random-write workload, CoW is pretty much the ideal file system layout, because it turns random writes into sequential ones.

                          Comment


                          • #14
                            " real-world benchmarks " == oxymoron



                            I, and anyone ithink, will agree using zeros is not 'real-world' of course but nevertheless it is a baseline, which ithink is what the author/tester was aiming to get(despite the tests being run on unstable kernel, unstable btrfs and ext4( with, IMO, dubious stability ).

                            Maybe the compression test(s), at least, could be better. It would be, ithink, more constructive to suggest how to achieve something closer to end-user(desktop & server) usage rather than waste BW discussing effectively dead or old fs that have neither journal or CoW safety nets.

                            ...

                            Comment


                            • #15
                              iozone write parameters

                              I'm Chris Mason, one of the btrfs developers. Thanks for taking the time to benchmark these filesystems!

                              Someone forwarded me the iozone parameters used, and it looks like they have iozone doing 1K writes, which is less than the linux page size (4k on x86,x86-64 systems).

                              One way that btrfs is different from most other filesystems is that we never change pages while data is being written to the disk. When the application is doing 1k writes, each page is modified 4 times.

                              If the kernel decides to write the page somewhere in the middle of those four writes, ext4 will just change the page while it is being written. This happens often as the kernel tries to find free pages by writing dirty pages.

                              Btrfs will wait for the write to complete, and then because btrfs does copy on write, it will allocate a new block for the new write and write to the new location. This means that we are slow because we're waiting for writes and we're slow because we fragment the file more.

                              On my test machine switching from 1k writes to 4k writes increases btrfs write tput from 72MB/s to 85MB/s.

                              Numbers from another tester, all btrfs:

                              iozone -r1 (1k writes) 20MB/s
                              iozone -r4 (4k writes) 64MB/s
                              iozone -r64 (64k writes) 84MB/s

                              In practice, most people doing streaming writes like this use much larger buffer sizes (1MB or more). They often also use O_DIRECT.

                              -chris

                              Comment

                              Working...
                              X