Page 7 of 11 FirstFirst ... 56789 ... LastLast
Results 61 to 70 of 101

Thread: Real World Benchmarks Of The EXT4 File-System

  1. #61
    Join Date
    Jul 2008
    Posts
    1,726

    Default

    just look at lkml.
    Every month you will see reports for fs corruption and bugs - xfs and ext3.
    You hardly ever see a report for reiserfs.
    And it wasn't dropped because it was unstable - it was dropped because Namesys wasn't willing to add any new features. They wanted to put reiserfs in maintanace only mode. ext3 is much 'better' constantly adding features - and bugs.

  2. #62
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by energyman View Post
    just look at lkml.
    Every month you will see reports for fs corruption and bugs - xfs and ext3.
    You hardly ever see a report for reiserfs.
    And it wasn't dropped because it was unstable - it was dropped because Namesys wasn't willing to add any new features. They wanted to put reiserfs in maintanace only mode. ext3 is much 'better' constantly adding features - and bugs.
    Here is the exact reasons why suse dropped it.
    Hi all -

    We've been using ReiserFS as our default installation file system for
    the last 6-7 years now, and it's served us well in that time.
    Unfortunately, there are a number of problems with it, some purely
    technical, some more related to maintenance. I'll outline a few of the
    larger issues and offer my solution as a conclusion.

    ReiserFS has serious scalability problems. David Chinner's talk at OLS
    really underscored the problem well for a single, large, high bandwidth
    file system. While I realize that XFS-style scalability isn't a real
    goal for most users, ans isn't a target workload for reiserfs, the
    scalability problems are real. ReiserFS uses the BKL for synchronization
    everywhere, and since it's system-global lock, the problem doesn't go
    away when you split the file system into smaller ones. Lock contention
    alone is one problem, but it's made worse by cache bouncing between
    processors on larger systems.

    ReiserFS has serious performance problems with extended attributes and
    ACLs. (Yes, this one is my own fault, see numerous flamewars on lkml and
    reiserfs-list for my opinion on this.) xattrs are backed by normal files
    rooted in a hidden directory structure. This is bad for performance and
    in rare cases is deadlock prone due to lock inversions between pdflush
    and the xattr code
    . The quota code gets around this, but the fix would
    result in huge amounts of wasted space with ReiserFS. With increasing
    deployment of SLES as samba servers, and perhaps NFSv4 servers, the use
    of extended attributes will only increase.

    ReiserFS has a small and shrinking development community. Right now, the
    only developers really working with ReiserFS are Chris Mason, Jan Kara
    (internally), a rotating member of Hans Reiser's team, and myself. All
    of us have projects we're very much more interested in than working with
    ReiserFS. While Jan and I will be continuing to support ReiserFS for
    SUSE, Hans is increasingly (hard to believe) pushing people to use
    reiser4. Chris has moved on to Oracle and has expressed his opinions on
    leaving ReiserFS behind.

    ReiserFS v3 is a dead end. Hans has been pushing reiser4 for years now
    and declared Reiser3 in maintenance mode. Any changes that aren't bug
    fixes are met with violent resistance. Reiser4 is not an incremental
    update and requires a reformat, which is unreasonable for most people.
    Reiser3 lacks a number of features that other file systems either have
    or are adding soon, such as extents and growth beyond current limits.
    Since it's in maintenance mode, that's unlikely to change. I view
    reiser4 as an interesting research file system, but that's about as far
    as it goes. I've been unimpressed with its stability so far. I don't
    know how advanced the recovery tools are yet, but I suspect that the
    complexity of the format and the ability to essentially define the
    format on-the-fly with plugins will make a useful fsck extremely difficult.

    The solution for replacing an aging file system isn't to switch to a
    brand new unproven file system, but rather a proven one with a clear
    upgrade path. That file system is ext3.

    Ext3's performance in some situations may not be on par with Reiser3,
    but it scales better and Andi mentioned the other day that there is
    quite a bit of research going into improving the locking and general
    performance of ext3 going on right now, and since reiser3 is stagnant, I
    don't doubt they'll pass them soon.

    Ext3 has a much larger development community out there. Most other
    distributions use ext3 as their default file system, so bugs that don't
    end up getting reported to us and are fixed by other developers, we get
    for free - most Reiser3 fixes originate from Chris or I.

    Ext3 has a clear upgrade path. There is quite a bit of interest in the
    community in improving ext3, and ext4 is already under development. Like
    the upgrade path from ext2 to ext3, the path to ext4 is clearly defined.
    Existing file systems can be updated easily, and new files will be able
    to take advantage of the new features. Features already written and
    queued up include extents, a 64-bit journal, and 64-bit file sizes.

    Most of the institutional knowledge of reiserfs is bouncing around in my
    head. Jan has been getting his hands dirty a little bit, but beyond
    that, finding additional developers with reiserfs experience will be
    extremely difficult and I'd call training additional developers a wasted
    effort. Since reiserfs is in maintenance mode, the effort needed to
    continue to support it in future releases should be shrinking.

    To be clear, my long term goal is to use OCFS2 (or another CFS if one
    shows a clear adoption advantage) for the root file system. This would
    enable single-instance clustering at both the physical and the virtual
    distribution level and get us ease of management and flexibility in HA
    deployments. Realistically, though, desktop users are likely to continue
    to use ext[34] for the foreseeable future. Until we have OCFS2 (and the
    rest of the distribution) ready for such a deployment described above on
    larger servers, ext3 would be a suitable choice across the board.

    - -Jeff

    - --
    Jeff Mahoney
    SUSE Labs

  3. #63
    Join Date
    Aug 2006
    Posts
    158

    Default

    Quote Originally Posted by energyman View Post
    just look at lkml.
    Every month you will see reports for fs corruption and bugs - xfs and ext3.
    You hardly ever see a report for reiserfs.
    While that reflects the stability of those filesystems, it's also slanted by their popularity/exposure. In other words, given 2 filesystems of equal quality, one twice as popular should average about twice as many bug reports. Simply counting bug reports would mistake obscurity for stability and broad exposure for bugginess.
    Last edited by StringCheesian; 12-06-2008 at 04:22 AM.

  4. #64
    Join Date
    Jul 2008
    Posts
    1,726

    Default

    and how many users use need acl/xattrs? I know many linux users personally - and not one needs or uses any of the two. BKL is a red herring too. The BKL is used in so many places in the kernel, that the BKL usage of reiserfs is just a drop into an ocean. Same for 'scalability'. Who cares that reiserfs does not deal as well as xfs with 10s of disks, and several terabytes of data?

  5. #65
    Join Date
    Dec 2008
    Posts
    45

    Default

    Sorry, but you're losing credibility. As others have said, these tests are mostly useless: CPU bound or huge files. Do we really have to point out some relevant benches such as kernel compilation, boot-time or rsync archives ?

  6. #66
    Join Date
    Sep 2006
    Posts
    353

    Default

    Quote Originally Posted by reavertm View Post
    I'm using reiserfs ('3') for at least 5 years and I never ever had any data loss nor filesystem corruption. It handled perfectly every power loss I occured. It's rock stable and is eating alive ext3 when it comes to performance.
    I'm using reiser3 for at about 7 years and I never ever had any data loss nor filesystem corruption. It handled perfectly every power loss that occured. It's rock stable and eats ext3 alive when it comes to performance.

    There was one exception when using QEMU (most likely due to various Gentoo saboteurs getting to the code) which you can read about here:

    http://linux.50webs.org/gentoo/qemu-gentoo.htm

    A quote from that page:

    "I would have usually formated /dev/hdb3 with the Reiser3 filesystem, however, this usually extremely reliable filesystem, has been deliberately sabotaged. This sabotage causes massive corruption of files after a short time. By comparison, I have used the Reiser3 filesystem for nearly ten years (actually about 7 or 8 years (there was no ext3 when I changed)) now and have never had any corruption, at all, on any of my many Reiser3 boxes."

  7. #67
    Join Date
    Sep 2006
    Location
    PL
    Posts
    910

    Default

    jade, i have found a _real_ conspiracy for you :

    check this out:

    http://repos.archlinux.org/viewvc.cg...LD?view=markup

    this is a gcc build script for arch linux :

    Code:
    if ! locale -a | grep ^de_DE; then
        echo "You need the de_DE locale to build gcc."
        return 1
      fi
    it must be an german conspiracy to take over the world! ;-)

    that aside, it still beats me what does it need de_DE for ?

  8. #68
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,108

    Default

    From LFS:
    The following instructions will install the minimum set of locales necessary for the optimal coverage of tests:
    It's for the test suites.

  9. #69
    Join Date
    Sep 2007
    Posts
    122

    Default

    ReiserFS, with its balanced trees, is extremely sensitive to CPU and memory errors. Imagine a RAM module goes bad, and you only notice it a few days later. This can be too late already and half the file system is destroyed. It's what happened to me.

    Anyway, I don't see what all the fuss is about. ext3/4 are stable, perform well and have an okay feature set for most uses.

  10. #70
    Join Date
    Jul 2008
    Posts
    1,726

    Default

    ext3 is not stable, and ext4 is pre alpha code.

Tags for this Thread

Posting Permissions

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