Page 1 of 2 12 LastLast
Results 1 to 10 of 30

Thread: Btrfs Battles EXT4 With The Linux 2.6.33 Kernel

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,636

    Default 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. #2
    Join Date
    May 2008
    Posts
    598

    Default

    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.

  3. #3
    Join Date
    Dec 2009
    Posts
    18

    Default

    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.

  4. #4
    Join Date
    Mar 2009
    Posts
    141

    Default

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

  5. #5
    Join Date
    Dec 2009
    Posts
    18

    Default

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

  6. #6
    Join Date
    Sep 2009
    Posts
    2

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

  7. #7
    Join Date
    Jan 2010
    Location
    NE AR
    Posts
    22

    Default

    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.

  8. #8
    Join Date
    Dec 2009
    Posts
    18

    Default

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

  9. #9
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,587

    Default

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

  10. #10
    Join Date
    Dec 2009
    Posts
    18

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •