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.

    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
    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; 22 January 2010, 09: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

                    Working...
                    X