Page 1 of 3 123 LastLast
Results 1 to 10 of 30

Thread: Btrfs Battles EXT4 With The Linux 2.6.33 Kernel

  1. #1
    Join Date
    Jan 2007
    Posts
    13,405

    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
    Dec 2009
    Posts
    18

    Default

    Quote Originally Posted by sektion31 View Post
    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.

    Quote Originally Posted by sektion31 View Post
    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 at 08:12 AM.

  8. #8
    Join Date
    Sep 2009
    Posts
    2

    Default

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

  9. #9
    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.

  10. #10
    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.

Posting Permissions

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