Linux and Open Source Blog

September 27, 2006

SUSE 10.2 Ditching ReiserFS as its’ default FS?

Filed under: SUSE — E@zyVG @ 9:01 am

A letter by Jeff Mahoney from SUSE Labs

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.

If so, I think I will go with old and tested ext3, but XFS is also an option. I will need to do a small research for my decision. The only prob with RFS was that it mounted slowly, but wasn’t a big deal.

Which one you are going to opt for?


  1. Several years ago, after an analysis less perspicacious than yours, we decided that the conservative choice for a journalled filesystem was ext3, and converted all our ext2 filesystems. We’ve been happy with it ever since. The upgrade was easy, and our research indicated very few if any bugs blamed on the filesystem code, which our own experience bears out.

    Comment by Jim Carter — September 28, 2006 @ 2:39 am

  2. The main advantage I’ve found to reiser3 over ext3 is the amount of space taken up by inodes. We have an archive machine that creates a hard linked copy of the previous day’s Debian repository every night and then rsyncs the live repository to replace the files that have changed. This worked for six months on a reiser3 system, but it filled up an ext3 system in a few days. This is about 60 Gig of storage, using maybe 200,000 new inodes (and an almost insignificant amount of storage) each day, and it quickly filled up a 200 Gig drive.

    Comment by David Fox — October 2, 2006 @ 5:43 pm

  3. What’s wrong with XFS? I have only had a quick look at it (using it on a back-up hard-drive), but is seems like a very solid file system to me. I haven’t heard about any problems with it and I am considering using it as my main file system in future. So if you choose not to use XFS, I’d like to know the reasons why… I might change my mind.

    Comment by Chavoux Luyt — October 2, 2006 @ 7:47 pm

  4. There are many other Filesystems for Linux? Have you considered them?
    What about IBM’s JFS?


    Comment by Rob Kennedy — October 2, 2006 @ 7:50 pm

  5. My opinion … well … the FS that I have used during my experience are ext2, ext3 and ReiserFS. ReiserFS cause it was default for SUSE, so if ext3 will be default for openSUSE 10.2 then I am going for it.

    But I also want to try out XFS, as this fs seems very good for collection of small files, so as I have two hard drives, one 300GB as primary with OS and second 200GB with all music and movies, I will go for XFS for 200GB one …. the question is how easy it is to convert my current 200GB ReiserFS partition to XFS w/o loosing or moving data … I haven’t digg into this as of now. Does XFS support transformation from ReiserFS w/o loosing data?

    Comment by E@zyVG — October 2, 2006 @ 10:22 pm

  6. It is a very good idea that openSuse will be changing its default format from ReiserFS to Ext3.

    In my opinion, if we want our Linux’ses to improve, instead of increasing the differences between the diff Linux Distributions, we should try to decrease them.

    It is much-much better for All Linux OS’s to adopt Ext3 than to have 10 diff formats “flying” around…

    Lets make our lives easier!!!

    Bravo Suse, good choice!

    P.S.> I also hope that in one day, Suse, Ubuntu & the Rest, will also decide on one install method: either rpm’s or .deb’s.
    Such fundamental decisions will help the people use/adopt Linux in tenfold…!!!
    Not to mention that developers won’t have to create/support packages in 10 different install formats either…!!!

    Comment by Dimitris — October 2, 2006 @ 11:03 pm

  7. I’ve tested thoroughly ext2, ext3, reiserfs3, xfs and jfs 3 years ago, and I did some other tests more recently on bigger systems. Here’s what I found so far :

    ext3 is damn slow. Little problems, no corruptions, but sloooow.

    reiserfs behaves extremely well with lots of small files and have quite a good performance. I had some corruptions with bad hardware, though.

    xfs rocks for huge filesystem (I’ve tested 1 to 20 TB so far) and big files. Well, though it supposedly isn’t very well integrated to the kernel, I never had a single glitch with it. Back in 2000, I used to use it for all partitions of my systems (RedHat 7.x) and it was fine though performance degrades when logging IO dominates, so you’d better use some other log device.

    jfs works well and scales fine, but isn’t as fast as xfs. It’s pretty good, but I never used it intensively.

    I currently always use reiserfs for system partitions (root, /var…) and xfs for storage partitions, and all is well. I have a couple of ext3 partitions on my office PC too, but it isn’t as fast as reiserfs for everyday use.

    Comment by wazoox — October 3, 2006 @ 12:18 am

  8. Very interesting yes, but will reiserfs be available as an option or alternative to ext3 in openSUSE 10.2? Or will it be completely replaced?

    Comment by jack — October 3, 2006 @ 3:08 am

  9. Its a shame that after all this years its going to such result. I will stay with reiserfs on old servers, and already have reiser4 on few new…

    Comment by SchAmane — October 3, 2006 @ 4:44 am

  10. As of SUSE 10.1 I switched from SUSE’s default of ReiserFs to XFS and I found the following fairly recent articles helpful in supporting my decision. I am satisfied with XFS, it definitely mounts large volumes much faster than RFS and seems to be just as fast with all sizes of files. XFS also seems to have a fairly complete set of admin tools including a defragmentation utility, something that I’ve never seen for RFS, but I’m not sure if RFS even needs defragging.

    My vote goes for SUSE to use XFS, after all isn’t OpenSUSE supposed to be on the leading edge? If ext4 proves to be a decent fs, then maybe it will be the next leading edge fs for SUSE to adopt.

    Comment by Allen Cuda — October 3, 2006 @ 5:00 am

  11. I would really urge all to consider XFS. I had used it as the default file system for my SuSE installs from 8.2 through 9.3, and just recently started using the default Reiser out of laziness, I guess.

    But XFS would recover, and was extremely stable. If there is a reason for not using XFS, what is it?

    I had installed a few systems which used ext3 and they were slooooooow. Please don’t go there.

    Comment by erich friesen — October 3, 2006 @ 7:33 am

  12. Seems like XFS is in demand here (this post) and is preferred one. Ok, if someone knows:

    1. What about the compatibility - like latest kernels and FS related applications
    2. Does it fragment so much that I will need to use defrag util … i don’t want it (the plus side of Linux FSs)
    3. Converting partitions to XFS from ReiserFS 3.6 w/o loosing data, nor data corruption …. very imprortant aspect.

    Regarding JFS, I am quite sure that this one is not an option for my home pc.
    It really seems as if ext3 is good option, but seems slow compared to reiser and XFS. Maybe ext4 will have some nice features and performance under its’ sleeves.

    Comment by E@zyVG — October 3, 2006 @ 11:15 am

  13. Another vote for XFS, but it would be nice if it also had filesystem shrink suppport.

    Comment by Jeff Rollin — October 3, 2006 @ 6:01 pm

  14. Frankly, I simply can’t understand why there is a question here. XFS, which I call the eXcellent File System, is simply excellent. Over the last 4 or so years I’ve put it on everything from laptop’s / partion containing the boot directory to multi-terabyte raids and it has never once failed me.

    I’m a huge Suse fan, use it everywhere but have never once understood why it used Reiser as a default file system. Just choose XFS and have done with it -

    Comment by Michael Folsom — October 3, 2006 @ 6:11 pm

  15. I’m sure dumping reiserfs doesn’t have anything to do with this:

    It’s a tough call. But I don’t see too many folks carrying the reiser4 ball. Not a whole lot of kernel guys liked Hans personally. Ext3 isn’t as mature as resier3, but both are aging. There is just a less frictioned path with ext4 than reiserfs4.

    So good call I guess. I dunno, but reiser has served be well. Just the future doesn’t look so great now with Hans taken out of the picture.

    Comment by Thoreau — October 3, 2006 @ 6:26 pm

  16. At my place of employment, we made a wholesale switch from reiserfs to ext3 about a year ago.

    The thoughts that went into this haven’t been mentioned in the comments, so I thought I would add them.

    We are operating in a SAN environment with virtualized storage (net result: don’t try to tell me that the hardware is bad, that’s a laughable assertion in this sort of environment). Using Reiser, yes, operation was very fast, and it handled large numbers of files in a single directory very well, and yes, its inode overhead was quiet low.

    We ran into one, HUGE, problem with it, however. In a SAN environment, failures in the SAN can result in *temporary* disruptions in connectivity to the SAN storage system (much like an ethernet failure can result in IP connectivity temporarily dropping and data transfers being retried). This should *not* cause a filesystem to corrupt itself, or in the worst case, a journal replay should restore consistency to the filesystem. This was not the case with reiserfs. We had several instances where SAN connectivity disruptions caused the filesystem to get corrupted and require a “reiserfsck –rebuild-tree”.

    Ok, that sucks, and eventually might have caused us to switch on its own, but that’s not the end of it. An additional problem is that reiser journalling does nothing to protect the contents of the files on the filesystem (ala, “data=journal” in ext3), so even after a reiserfsck, we would find files (most commonly log files that are heavily written to) with part of the file containing contents from other files and just some general scrambling. This is a much bigger problem, and almost certainly would have caused us to switch fairly quickly, but that’s still not the end of it.

    The load of bricks that broke the camel’s back was the repair performance. When we did have glitches that caused filesystem corruptions, the time it took reiserfs to repair the filesystem was totally unacceptable. Just an initial check to see if the filesystem needed to be repaired on SLES7 took 3 hours(!), and a –rebuild-tree took 6(!!). After we upgraded to SLES8, the times dropped to a cumulative 3 hours (I think it was about 45 minutes and just upwards of 2 hours for the check and –rebuild-tree time respectively). When we switched the filesystem to ext3, a full check and repair took 20 minutes, start to finish.

    So, to sum up, yes, moving to ext3, we did drop some performance, but we went from having to take extended downtime to repair our filesystem every couple of months, to only having had to do that once since we switched, and when we did have to do it, it taking a fraction of the amount of time to get back into service. So, ext3 is *much* more robust and reliable than reiser, and when problems do occur, *much* faster to get back into service.

    We’ll take MTTR (Mean Time To Repair) over regular performance any day…we can overcome performance other ways…repairing a hosed filesystem is not nearly so easily overcome.

    Separately, about the time we were doing testing/benchmarking of these filesystems, SuSE/Novell announced that they were deprecating JFS in its distributions. Our testing resulted in ext3 and JFS being the prime contenders in our filesystem choice at that point. We decided on ext3 because we had experience and skills in-house with ext3 already, and basically none with JFS (we were in the mood to be conservative, given our travails with reiser that we were experiencing). We were, however, extremely pleased with the results that we were seeing with JFS and were strongly considering its use in the future. We were then extremely disappointed in SuSE/Novell’s decision to deprecate it. We would put our hat in the ring, as a rather large SuSE/Novell user to encourage SuSE/Novell to rethink that decision.


    Comment by Jeff — October 3, 2006 @ 6:30 pm

  17. any response to these comments on xfs quoted at

    The world of open source software has had a fair share of fights over the years (Emacs vs Vim, KDE vs GNOME, LILO vs GRUB), but what about the different Linux file systems? Those readers with interest in the subject might find it interesting to note that no fewer than four well-known Debian developers came out against using XFS during the past week. Martin Krafft: “I am through with XFS, once and for all. I still think it’s a good filesystem when you can ensure that the power never goes, and your hardware is reliable, but it’s just not adequate for laptops or even desktops.” Julien Danjou: “I regularly spite on XFS, and I am quite amused that more than 2 years later, XFS is still totally crap!” Gunnar Wolf: “About to say goodbye to XFS as well.” Erich Schubert: “I’m going to join madduck, Gunnar Wolf and Julien with their negative experiences with XFS.” Coincidence? Or is XFS starting to get a really bad reputation among hard-core Linux developers?

    Comment by simon kert — October 3, 2006 @ 6:55 pm

  18. As this is a very seriuos situation we can’t step forward
    with only suppositions…

    We need real data, real facts, real tests and real results.

    To take a decision we must first put the facts on the table (a’la MS):

    * How many Journaling File Systems Exists??
    - XFS (The one made by Silicon Graphics?)
    - JFS (the one made by IBM?)
    - ReiserFS v.3 (mantained by Jeff)
    - ReiserFS v.4 (Hans?)
    - ext3 (Mantained by Dr. Stephen C. Tweedie from RedHat?)
    - And some more not considered

    * What features, advantages, disadvantages, between them, are important
    to consider?
    - Speed
    - Community Support
    - Stability
    - Reliability
    - Latency
    - Scalability
    - Inode Size in time
    - Wasted Space
    - etc, Continue….

    * Who can Perform this tests (a’la Tom’s Hardware) ??
    - With real graphics
    - Real Advantages
    - Real Disadvantages
    - Tools Available for each FS
    - Future Plans of each FS

    * And finally(considering this facts) which FS is better than who And Take a

    I can’t figure out why anyone has made this kind of comparisons between FS’s
    and can’t believe the unawareness between companies to make an unified effort
    for making an stable, planned, unified, Journaling FS. Remember UNITED LINUX?
    this kind of things are once again needed to make Linux prevail.

    Comment by Israel Cabrera — October 3, 2006 @ 6:58 pm

  19. As a correction/clarification to comment #16.

    We use the default of “data=ordered” on ext3, which doesn’t completely prevent file contents being scrambled, but does still dramatically reduce the chances compared to reiser’s behavior.


    Comment by Jeff — October 3, 2006 @ 7:12 pm

  20. The company I work for has an XFS on Linux based product, so I have quite a bit of experience digging around the XFS code and using XFS on big/fast storage (multi-terabytes, hundreds of MB/s of throughput). And for that kind of usage, its the only Linux filesystem that works. That said, it has many problems:
    1. It has been known to deadlock and corrupt when it gets full
    2. They put so much stuff on the stack, its unusable with 4K stacks, which are becoming the norm.
    3. The code is horrible, especially when you compare it with ext2/3. It’s not native, and they have a “compatilibily layer” where the linux specific code is. Its algorithms are super complex so its hard to manage and debug.
    4. It has lots of bugs, at any point in time, our kernel tree has 5-10 XFS bug fix patches

    Comment by Tester — October 3, 2006 @ 7:14 pm

  21. SUSE 10.2 Ditching ReiserFS as its Default FS

    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 …

    Trackback by osViews | osOpinion — October 3, 2006 @ 7:24 pm

  22. I’ve heard nightmare stories with XFS, ReiserFS and i was bitten two times by Ext3 (but i was using an early 2.6.1 kernel at that time =).

    Times ago i’ve read an interesting analysis about PC hardware and filesystems:

    The sum: PC hardware is of discutible quality so your FS is going to fail, if you don’t take appropriate measures… =)

    Comment by Andrea — October 3, 2006 @ 10:31 pm

  23. Wow … I am getting a lot hits on this post, and the link to this post is being sited on some major Linux dedicated sites as well as some blogs.

    I am getting afraid a little bit :) I hope i haven’t created some sort of fud/rumour down here.

    It would be good to see some comment(s) from Jeff Mahoney himself (unless above Jeff is the one)

    Comment by E@zyVG — October 3, 2006 @ 11:00 pm

  24. A huge problem for me with EXT3 is the inability to resize dynamically in LVM. With ReiserFS 3.6 I can shrink and grow partitions on the fly while people are using it. Will this ever be possible for EXT3?

    Comment by Krondor — October 3, 2006 @ 11:32 pm

  25. The above Jeff (comments 16 and 19) are not Jeff Mahoney. Sorry about that. Didn’t even think about the potential confusion.

    Jeff McAdams

    Comment by Jeff — October 3, 2006 @ 11:43 pm

  26. I have been running XFS for some time now, and there are things about it that I love and a few things that I love not so much. One of my concerns is that the support for the XFS related utilities seems to be ill defined. For example: I recently ran into a problem where I really wanted the -M with multiple -f flags to work. The documentation on XFS appears to have been last updated in 2003; an email to one developer at SGI got forwarded to a second developer at SGI, who informed me that multiple -f options are still not supported in xfsdump; the multithreaded support is actually in the code but is commented out. The sense that I got is that this code has been passed off several times.

    I would like to know more about the the current state of XFS support.

    Comment by Christopher Piggott — October 3, 2006 @ 11:45 pm

  27. I also vote for XFS. I’ve used it as the main FS for Suse, Fedora, and even RHEL boxes. Performance is good, scalability is definitely there, and seems to be decent for everything from laptops to SAN systems.

    Comment by Ammon — October 3, 2006 @ 11:48 pm

  28. There’s been a lot of buzz about XFS, but what kind of future does it have? It’s developed by SGI, and that’s a sinking ship. I just worry that nothing will happen with XFS while Ext and ZFS leave it in the dust.

    Comment by Stack — October 4, 2006 @ 12:24 am

  29. Someone pointed out to me that my email was spreading, so I guess I’ll say a few words.

    I’ve seen a number of questions and misconceptions in some of the posts above, so I’ll try to address a few of them.

    The headline is a little bit misleading. My quoted email was a proposal, not an announcement. I wanted to gauge how well such a change would be viewed by the community before we made any changes. The proposal was well received, but we’ll probably be waiting until openSUSE 10.3 before we change the default file system.

    This proposal has absolutely nothing to do with Hans, the friction we’ve had in the past, or his current legal troubles. Despite the impression that some of our more visible email exchanges may have given, we’ve actually had a decent working relationship. In fact, I had posted this email several hours before the article referenced in comment #15 was pointed out to me for the first time and I was concerned that people would make a connection where none existed. To repeat: the timing is entirely coincidental and the motivation is unrelated.

    Like the comments posted with this article, the most common response I received was - “Great, but why not XFS?” The reasons behind this are pretty straightforward. XFS is a good file system too, but it’s several orders of magnitude more complex than ext3/jbd. It’s almost six times the amount of code, there’s an ugly Linux->IRIX compatibility layer in the middle, and the XFS development community is relatively small. Since the size of the support community is one of my reasons for proposing a switch away from reiser3, a switch to XFS wouldn’t address that.

    This is only a proposal to change the default file system. We’re not dropping support for reiser3. Having a number of options for a file system is important, since each can excel for specialized workloads. reiser3 is great at handling lots of small files, but can run into problems with streaming media or a high degree of parallelism. David Chinner’s talk at OLS this year showed just how impressively XFS can scale for high bandwidth, highly parallel, streaming media workloads. That workload is XFS’s sweet spot, it has problems in other areas, such as running out of memory while deleting those huge trees of small files that reiser3 handles so well. For most users, though, the choice of a general purpose file system isn’t that important. For your average notebook, desktop PC, or small server, the workload isn’t specialized enough for the choice of file system to make a lot of difference. Benchmarks may highlight one file system over another, but they’re typically such extreme workloads that the average user won’t usually run into them.

    There are several reasons I proposed ext3 as the default file system. It performs well as a general purpose file system. It has an outstanding set of support, recover, and debugging tools. Just as users could upgrade their ext2 file systems to ext3 easily, the update to ext4 is planned on being similiarly easy. A switch to reiser4 from reiser3 is a backup-and-restore operation, not an upgrade. ext3 gives users a clear evolutionary upgrade path. Most importantly, though, it’s not very complex, it’s deployed everywhere, and there are a huge number of people out there who understand how it works internally.

    I hope this clears a few things up. :)


    Comment by Jeff Mahoney — October 4, 2006 @ 12:47 am

  30. I have used JFS for a year or so, but last data a couple of times after a crash and sometimes experiences kernel lockups.

    Went to ext3, haven’t had a single problem.

    Comment by Berend de Boer — October 4, 2006 @ 12:59 am

  31. Jeff,

    IMHO you should strongly consider XFS over ext3. We have seen many performance issues on customer systems running ext3. We and Intel have spend a lot of time and effort trying to figure out what is going on, to no avail. We have never seen an issue with XFS. One problem in tracking the issues with ext3 is that the problem is not consistently reproducible. Sometimes the performance is as expected and then you run the same workload again and the performance sucks. Customers stuck with distributions not offereing XFS fall back to ext2, of course you never want to have a crash or you’ll spend days running fsck.

    In short, from the HPC point of view XFS is the right choice w.r.t. performance and getting no issues.

    Comment by Robert — October 4, 2006 @ 1:02 am

  32. Why use OCFS2, GFS, or whatever clustered filesystem for the root filesystem? Seems to me that would degrade overall performace. If you want a clustered filesystem for Xen machines or whatever, great, do it on a separate filesystem though. There’s no point in degrading the performance of the whole system when you only want a portion to be a clustered filesystem.

    Comment by Chad Groneman — October 4, 2006 @ 1:02 am

  33. It seems strange to me that JFS isn’t the FS of choice: been using it on production server for an year now and seems very well performing and stable to me, particularly with ACLs and attributes, with wich is on par only with XFS (here reiserfs and ext3 perform from bad to worse…). Didn’t have the opportunity to test it on large arrays though.

    Comment by Albe — October 4, 2006 @ 1:12 am

  34. A relatively recent file system comparison can be found here:

    I wonder why some people insist that XFS gives zero problems. Just take a look to the XFS FAQ and scroll down to the question “Why do I see binary NULLS in some files after recovery when I unplugged the power?”:

    I haven’t experienced this problem though. My experience with EXT2/3, XFS and JFS are very positive up until now. Not so with ReiserFS and I agree that it’s best avoided.

    Comment by velko — October 4, 2006 @ 1:28 am

  35. I make heavy use of ext3, JFS, and XFS. I was using a lot of ext3 and ReiserFS, but we’ve been moving away from both for most purposes lately. ext3 we most commonly use for /boot (and have no plans to change that), and frequently for /. Pretty much everything else we’ve been going with JFS and XFS. Both have performed very well for us, and so far, we haven’t determined a clear “winner”.

    One of the reasons we’ve been moving away from ext3 and ReiserFS are specific performance issues. ext3 is very slow on deleting large files, and certain other operations (it had particular issues with large directories until recently, sometimes still does). ReiserFS takes a *long* time to mount and unmount. This became a specific problem with a 2TB array that literally took on the order of 30+ minutes to mount and unmount sometimes. Now, we try to keep our reboots infrequent, but that is seriously excessive, and entirely too long to use in a production machine that we need to maximize uptime on.

    All in all, my suggestion is ext3 for low-level system files (due to the fact that these are utilized less frequently, tend to be small, and there’s more recovery tools available for ext2/ext3), and JFS or XFS for everything else.

    Comment by Christopher Cashell — October 4, 2006 @ 1:45 am

  36. We use XFS extensively on all our machines. XFS performance and scalability is fantastic.

    Comment by Shiv — October 4, 2006 @ 1:47 am

  37. […] Mandriva Linux 2007 | OpenSuse dejar� de usar ReiserFS OpenSuse, uno de los tradicionales sistemas que ven�an usando usando ReiserFS, anuncia que parasu pr�ximo lanzamiento, OpenSuse 10.2, no utilizar�n este sistema de ficheros por defecto. Comentan que el mayor problema de ReiserFS es la escalabilidad, y es por ello que se han pasado a ext3 a pesar de la p�rdida de rendimiento. M�s detalles aqu�. […]

    Pingback by :: Te ponemos al dia » OpenSuse dejar� de usar ReiserFS 2.0 — October 4, 2006 @ 1:55 am

  38. SuSE has been the only distro of my entire Linux life, I don’t remember exactly but I think I switched to ReiserFS 3 almost as soon as they did. So far, RFS3 never failed on me, even with hardware problems. I never lost a single file since I started using it and even if it isn’t always the fastest FS, I still have to find a reason to switch to anything else.

    The fact that RFS3 will be deprecated sooner or later is a good reason to think about such a switch. However, in absence of a good objective –and recent– comparison of all the available filesystems, I don’t know yet what will be my next FS. I don’t feel like switching to the “old” Ext3 FS that I never used… Ext4 FS looks like to be going to spend most of its time wondering if it should do Ext3 or Ext4 stuff… ReiserFS 4 seems to require even more horsepower than RFS3.

    I guess I’m going to stick with RFS3 as long as possible and hope for the release of one of these mythical database filesystems we’re all waiting for.

    Comment by Maxilys — October 4, 2006 @ 2:09 am

  39. Ext3 can only handle filesystems up to 8TB. With harddrives already reaching 0,75TB, it’ll be a matter of time until ext3 is obsolete. Such large filesystems already exists and EXT3 is already obsolete there. Switching to ext3 this late seems rather foolish to me, I’d say there is less than 5 years of life in it.

    A “fixed” ext3 can be expected and will require disk format changes. Ext3 is therefore no more realistic than Reiser4. While I definately like the vision and design behind Reiser4, it is not ready to be used as default filesystem. XFS is the most realistic future proof filesystem at this time.

    Comment by Daniël Mantione — October 4, 2006 @ 2:15 am

  40. We (as GNU/Linux community) need new filesystem. Look @ ZFS from Sun and cover in shame. Hopefully ext4 will be just as good.

    Comment by boniek — October 4, 2006 @ 2:18 am

  41. Only one question, what will SUSE do with the default recheck of an ext3 filesystem ? on boxes with very large filesystems, would it not be worse then the slow mount time of RFS to have to wait multiple mins/hours before a system boots up onces a month ?

    I also ask this to the people using ext3 on large sans/clustered storage.. do you people disable the max_mounts_count options ? if so, do you trust ext3 enough to never get (slightly) corrupted (aka in need of the max_mounts_counts fsck) ?

    Comment by Saber — October 4, 2006 @ 2:32 am

  42. People,

    do not forget that openSUSE is especially for desktop-use and for Joe Average. For that matter we are searching for a new default filesystem. It does not have to support 20TB as an desktop-user would never request so much space.

    Another thing is that we can not make users switch with pain in the ass every time we have to upgrade the filesystem. Ext is doing I good thing there with as little pain as possible. We don’t know yet how that wil be with XFS.

    All those other filesystems are available too, so real server-masters can just select the one they wanted. This is all about default. Default filesystem for Default desktop-user.

    Ext is stable, clean, does have an huge developement-team and does the job for Average Joe. It may look that we choose for an ‘old’ filesystem but the other side is that upgrading in the future won’t be a problem so having an ‘old’ one is not a big problem/blocker.


    Comment by Azerion — October 4, 2006 @ 2:56 am

  43. @Chad, re Clustered FS as root:

    I should preface this by mentioning that everything I post on this site is as an individual interested in file systems and shouldn’t be taken as official statements or even a general direction of SUSE/Novell. Everyone has their own pet projects they like to work on. :)

    My plan is to evolve OCFS2 so that it can be an excellent general purpose file system. The disk format is extrenely well suited for this. OCFS2 uses larger inodes (a full block) which makes intra-cluster journaling easier, but it also yields interesting side effects. With 4k for each inode, things like symlinks, extended attributes, and file tails can all be inode-local. I’d also like to use some of that space, eventually, to include inode checksums or parity information for quicker (and potentially online) error recovery.

    So that’s my plan for the disk format, but that doesn’t directly answer your question. With respect to the “overhead” of using a cluster file system, the overhead need only exist when you actually need to communicate with other nodes. If you want to deploy your system as a standalone node, or even part of an unshared root HA cluster, there’s no need for your file system to assume any overhead for cluster locking. The locking operations will be no-ops.

    The advantage to this is that eventually, if whatever distribution you’re using is prepared for it, you can extend a cluster by simply booting a new node off your SAN hardware. Instant-on, zero-install capacity growth.

    Comment by Jeff Mahoney — October 4, 2006 @ 3:07 am

  44. @Robert (comment 31), Re: XFS

    I realize that XFS performs extremely well in HPC deployments - but that’s its sweet spot, and you’re absolutely welcome to continue to use it. XFS will still be available, but the undeniably large number of people who understand ext3 make it a better choice for the default in a desktop distribution. Performance problems like the ones you’re describing in ext3 are bugs, and should be reported as such. They may be annoying and hard to track down, but they’re bugs just the same.

    Comment by Jeff Mahoney — October 4, 2006 @ 3:15 am

  45. As a note to those complaining about the slow reiser3 mount times, the problem is that reiser3 loads all the bitmaps on the file system at mount time. It’s dumb and I released patches for that some time ago. They’ve been kicking around in the -mm kernel for a few months and were commited to mainline early this week. So, expect to see them in 2.6.19 as well as the openSUSE 10.2 kernel.

    Comment by Jeff Mahoney — October 4, 2006 @ 3:17 am

  46. @ Daniël (comment 38), Re: disk format change for both ext3->ext4 and reiser3->reiser4

    Daniël, the difference is that reiser3->reiser4 requires a backup/reformat/restore cycle, and ext3->ext4 should only require a single tune2fs command. Ext4 is already under development (there were some talks/BOFs at OLS about it). Some of the more obvious features targetted for ext4 are 64-bit block numbers (and journaling) and file extents. You can find a more complete list with google.

    Comment by Jeff Mahoney — October 4, 2006 @ 3:24 am

  47. Ext3 will let you resize with lvm, at least under Redhat/CentOS/Fedora.

    As for ext3 not going past 8TB, there is already talk of ext4 with ext2/ext3 like convertibility in the forward, but not necessarily in the backward direction.

    Comment by edgan — October 4, 2006 @ 4:51 am

  48. How about Sun’s ZFS?

    Comment by Ketchapay — October 4, 2006 @ 4:54 am

  49. […] Artículo completo en Linux and Open Source Blog. […]

    Pingback by » OpenSUSE abandona ReiserFS » Linux Platense — October 4, 2006 @ 6:09 am

  50. I think most people are missing the point that we would need to migrate (backup/format/restore) to any file system other than Reiser. In the near term there is no reason to migrate unless there are performance reasons. We currently use Ext2/3, ReiserFS, and XFS but each in it’s own place. We use Ext2/3 for the /boot partitions, ReiserFS for working storage, and XFS for our Large Media/Data requirements. CFS sounds like it might be interesting for our upcomming grid work - Reiser4 looks interesting as a way of making the the file/storage system “intelegent”. But I guess my point (and this may all just be rambling) but it really is great to have so many options and the be able to work with so many talented people who are exploring new ways of making system scale. The fact is that we are seeing 1 to 2 TB of storage start to be common and 10 to 50 TB will be common in the next 5 years.

    Think Media, think Podcast, Vodcast, Video, Audio, Pictures, medical devices that monitor and record in realtime. We are not going to want to delete most of this stuff.

    Linux and all of these projects are what is making it happen because of the communication, ideas, and sharing that is going on.

    This is only the beginning …

    Comment by RobertJF — October 4, 2006 @ 7:19 am

  51. […] …nu de tot, nu vă speriaţi. Renunţă la ReiserFS ca filesystem implicit. Cică după 6-7 şi-au dat seama că există anumite probleme de scalabilitate şi performanţă cu sistemul de fişiere. Se va folosi de acum EXT3 (desigur) dar planul pe termen lung este să se ajungă în cele din urmă la OCFS2. Sursa […]

    Pingback by OpenSUSE 10.2 renunţă la ReiserFS « — October 4, 2006 @ 8:00 am

  52. The problem that many people experience with any journaled file system is data loss. This is because many people believe that journalling keeps their data consistant, which is not the case. Journalling allows for fast recovery only. It does not maintain data consistancy whatsoever.

    The biggest problem with XFS is also it’s biggest asset. XFS relies extremely heavily on the filesystem cache. It uses it A LOT! It’s the reason it’s so damn fast, but it’s also the reason for significant data loss. If you’re computers are on a UPS or a battery backed up caching controller there’s no problem. Otherwise, you can run into issues. If you’re system is able to properly shut itself down in the event of failures and ensure all data is written to disk before going down there are no issues.

    All other journalled file systems will experience similar problems. The only way around it is to avoid using a journalled file system and run your mounts in sync mode, but then, everyone would be bitching their systems are as slow as mollassus in january flowing up hill.

    I still vote for XFS, it’s the _fastest_ file system out there. EXT3 is good, but it doesn’t perform near as well.

    Comment by SubAtomic Toad — October 4, 2006 @ 8:43 am

  53. My vote’s for ext3, only because most of my systems are dual boot. I’ve been setting them all to ext3 as I can install the ext2ifs under the windows partition and access my data. It’s also compatible with the imaging software we use at work (Ghost). If there’s options for XFS to be used under windows, I’d be happy to look at switching. Until then, it’s ext3 for me.

    Comment by Zenophran — October 4, 2006 @ 10:42 am

  54. Some people are claiming ext3 is a better desktop choice, but XFS is a fine desktop filesystem. What is bad about XFS on the desktop? It looks the developers are slightly biased in favour of ext3, but the users want XFS.

    Comment by Daniël Mantione — October 4, 2006 @ 10:55 am

  55. Ob. disclaimer: I’m not a SuSE user, but rather Slackware.

    I used XFS for media file storage, until the XFS defrag program (official version from SGI!) hosed almost 1/3 of my files. It mixed the contents of the files: text in MP3’s and MP3’s in text.

    I verified that it was a problem with the defrag a couple days later, on a much smaller filesystem.

    Yeah, XFS was fast. Fast at retrieval, and fast at scrambling.

    Comment by gus3 — October 4, 2006 @ 10:56 am

  56. By far and large this is good news about SuSE linux. I never understood why SuSE kept going with ReiserFS as default filesystem. My personal experience with it is as bad as it can possible get: on a perfectly 0815 working machine, install any SuSE with ReiserFS, wait for the reboot and at some time during the next reboot plug the power cord. Chances are around 30% that the filesystem is kaputt beyond repair. Or keep pulling the power cord a few more times. Eventually you end up with a dead filesystem. Try this with ext3 and you get anoyed beyond any further wish to try, but the filesystem stays intact. Even if ext3 journal dies, you can use ext2 tools to repair and fix the filesystem or in worse-case copy files from it away somewhere else.

    Second at work we recently installed a server with 11 TB (16 750GB SATA drives), and began installing SuSE 10.1, which suggested ReiserFS. Since ext3 stops at 8TB atm, we let it continue. The installation didnt work, 30mins after ReiserFS began formatting the PC hang and we had to reset out of the install. We ended up installing XFS which works fine and fast.

    Comment by Philipp — October 4, 2006 @ 12:25 pm

  57. This is a very good move.
    The only time we ever lost data was with ReiserFS. We used Ext3 ever since and had no trouble with it at all.

    Comment by Dale — October 4, 2006 @ 12:52 pm

  58. […] […]

    Pingback by Laurent’s Blog » Blog Archive » SUSE 10.2 Ditching ReiserFS as its’ default FS? — October 4, 2006 @ 12:54 pm

  59. |But I also want to try out XFS, as this fs seems very good for |collection of small files, so as I have two hard drives, one 300GB as |primary with OS and second 200GB with all music and movies, I will go |for XFS for 200GB one …

    Well, I am not very fond of 1 second movies or music files… Therfore I will stay with a filesystem that is good for collections of huge files.

    Comment by xmanoel — October 4, 2006 @ 1:18 pm

  60. My Experiences with Linux Filesystems:

    ReiserFS a.k.a. Reiser v3 works quite well and is a good default. I hardly never lost files even by not knowing/using the journaled data option. If it is not cleanly unmounted, it replays its journal after reboot almost all times. But it is not that reliable after all: Two or three times the tools said I had to rebuild the tree (fsck.reiserfs –rebuild-tree /dev/hdX) because there were inconsistencies that were not otherwise fixable. As far as I can say: DON’T do it, think twice or you will find some files mixed up. All you should do is to copy your still existing data to a spare disk, rebuild the tree and then compare them file by file. Much work, so you better have up to date backups. ;)

    The other experience with ReiserFS is that it does not like bad blocks in its journal. A friend of mine lost his data due to the fact that if the underlying blocks of the journal are physicaly damaged, ReiserFS can not read anything of its tree anymore. “I/O read error” is surely not what you are expecting of your beloved high performance space saving file system. And keep in mind: Some people claim that disk live is shortened by using transactional file systems. So you may end up the same.

    After experimenting with Reiser4 I can say: Not ready for prime time. Try to remount (mount -o remount) or unmount it in the wrong second and make it crash. Have an unexpected reboot and you may have to rebuild the tree using tools that are marked “experimental”. I repeat: “experimental”. You should believe it! I did not and lost some photos that were not on the backup and not otherwise recoverable. If the tools want you to rebuild the tree, then try to remount it read only and take the same steps as described above for ReiserFS v3. The consequences for me: No go.

    One candidate I also tried was XFS. Having made the above experiences with Reiser I searched for the draw backs of XFS in advance. One thing I found: Binary zeros after unclean unmount. See for this one. It is true as far as I can tell. You could use barriers as mount options, but this did not work in my device mapper (DM) setup. Having had some NULLed bash histories I lost faith and started to look for something realiable.

    What reliable means? In short: I want my files to look like after I saved them. Save should be save. I can not do backups every hour a day. The file system should do what most expect of it: Store files that do not disappear after switching of your box. However this switch off was done.

    My conclusion for now: EXT3 with data=journal. It meats the above expectations. It stores files and (almost) never loses anything. Have a power surge, have a crash and have your file system always consistent. Even bad blocks keep the journal readable as others reported. Sure this could be done with ReiserFS and the journaled data option but I wanted something rock solid, well supported and surprice free. EXT3 does it for me as I can tell. So if your are interested in a file system with very good capacity for remembering then use it.

    Comment by rajas — October 4, 2006 @ 1:22 pm

  61. […] OpenSuse (Suse) que desde hace muchas versiones venía utilizando ReiserFS como sistema de ficheros por defecto en su instalación, ha decido dejar de hacerlo para su próxima versión 10.2. Según Jeff Mahoney de SUSE Labs, el motivo de este cambio es debido a serios problemas de rendimiento, la imposibilidad de cambiar a ReiserFS 4 sin tener que formatear la partición en ReiserFS 3, a su reducida comunidad de desarrolla y a problemas de escalabilidad. […]

    Pingback by InaGotable » OpenSuse deja ReiserFS — October 4, 2006 @ 1:38 pm

  62. Probably showing my ignorance but what is happening with the NSS file system.
    As a network engineer I’ve used this on Netware and found it extremley fast both in load and access time, also extremely reliable and virtually uncorruptable.
    Novell have opensourced this and it ships with the OES Linux range so is there any reason why this is not a good option.
    Obviously it’s designed for a network environment but does this create a problem.
    Again excuse my ignorance but as I say i’m a network guy not a developer.

    Comment by NWAdmin — October 4, 2006 @ 3:20 pm

  63. I have used jfs extensively on all the servers I manage for a number of years. It has always been reliable, on the 30 odd servers I manage I have never experienced corruption or problems directly related to jfs. The jfs developers are very responsive to questions or problems. My understanding is that the code is fairly clean, having been ported from aix -> os/2 -> linux

    Comment by Jesse Hathaway — October 4, 2006 @ 4:14 pm

  64. ext3 isn’t perfect. I’ve been using both ReiserFS v3 and ext3 for a number of years. I have yet to lose any data to ReiserFS. I have personally lost 2 filesystems to ext3 corruption. My systems are not used heavily, mainly desktop, basic web server and backup uses. The drives that the ext3 systems were on are still running fine with ReiserFS partitions on them now.


    Comment by Brian C. Lane — October 4, 2006 @ 5:34 pm

  65. @NWAdmin

    Have you actually tried to *use* OES? That thing is *not* ready for prime time.

    We’re trying to stand it up to replace some Windows file servers here, and we can’t even get it fully installed without it horking all over itself.

    When we do get it installed to the point of seeming to function, to get it to actually do anything useful, we’ve had to open 4 calls with Novell, some of which have been open for months with absolutely no resolution, some of which have resulted in us being requested to replace scripts used in the management of OES manually (ie, outside of the package management or any sort of patching mechanism…meaning management, or rebuilding, of these machines just flew out the window).

    We *really*, *really*, want to use OES, but learn from our experiences and stay away from it until the next release…its just not ready for prime time.

    As for using NSS as a default, it is my understanding that NSS can’t be used as a system/boot drive, so that pretty much throws it out the window for this purpose right away. Also, much like the rest of OES, its barely useable on Linux at this point.

    Jeff McAdams

    Comment by Jeff — October 4, 2006 @ 5:42 pm

  66. Jeff McAdams,
    thanks for the heads up. I’ve never used OES Linux so I’ll avoid that. I was just querying NSS as an option as I know how rock solid and secure it is under NW, access and trustee rights that you can only dream off with anything else. Maybe NSS on Linux is somethimg for the future if Novell can get it working to standard it currently is on NW.

    Comment by NWAdmin — October 4, 2006 @ 6:25 pm

  67. I’m noticing that there are a few people asking about ZFS, but they are getting completely ignored. Why? From what I’ve read about ZFS it is absolutely worth considering!

    Comment by Roger — October 4, 2006 @ 6:36 pm

  68. This is my 2 cents from my experience.
    I had a couple of maxtor 5000DV external harddisk (ATA 133) with firewire interfaces.
    I purchased them to use as external and for capturing video for editing.
    With windows XP, adobe premiere, and the disk formatted with NTFS this worked fine and i was able to produce 2 DVD.
    But since i run linux as my desktop i wanted use it for this purpose also, so i formatted another disk with XFS.
    I used kino as the front end for capturing the video to disk. The capturing process would work good for a while, but for some reason after some time. The red activity light on the 5000DV would stay on constantly, the box would vibrate audibly, and after a that the disk becomes inaccessible and i was unable to recover any data. I would power it off and power it back on, after unmounting, to no avail. Beyond that when i removed the harddisk from its external case and put it directly in a system as a slave, the system would not boot at all from its primary disk. This happened twice, and i lost two 300GB harddisk in the process. As a solution, for the last 5000DV i had, i just removed it from the external case and connected it to an ATA 133 controller, formatted it with ext3, and have been using it internally on a fileserver, and haven’t had any issues.

    So i’m baffled as to what was really the source of the problem; was it the filesystem, was it the firewire interface, was it kino, or just bad disk. Short captures were ok, but it happened with long captures.
    Has anyone else experienced this.

    Comment by scribe63 — October 4, 2006 @ 6:59 pm

  69. Hello,

    I also vote for XFS. Whatever you keep as default, please keep XFS as a choice so that users who want the performance and robustness can select it and use.

    Thank you.

    Comment by Zaheer M K — October 4, 2006 @ 7:10 pm

  70. Yes, I agree that having ext3 as the “plain vanilla” install for Suse in the future is a good idea. However, it would be good to make using an alternate FS as easy as possible. An admin wanting to install Suse on 20+ boxes with XFS or ReiserFS would be anticipating a terrible pain. Alternate DVD, maybe?

    But ReiserFS is still the best IMHO for the average developer, since “lots of little files” is precisely what you are opening during a software build. And XFS is wonderful for industrial-strength production boxes. Remember XFS was developed at SGI when SGI was still cool, and its devs were the best.

    Comment by ishmal — October 4, 2006 @ 7:44 pm

  71. I’ve been looking at Sun’s ZFS demos and I’m blown away. I’m not a filesystem guru, but damn, it looks EASY TO USE! It’s also very scalable, and has tons of development going on. Why is the Linux community not checking this out? Hopefully not just because it’s Sun who’s doing it. Besides the obvious technical advantages of ZFS, wouldn’t doing a Linux port make it easier for the Solaris admin community to adopt Linux based on a common filesystem?

    I’m getting ready to switch from Windows servers and because of ZFS, I’m considering Solaris over Linux. It’s got a whole company behind it, it’s scalable, fast, and EASY to use! Should I not be?

    Comment by Bobby — October 4, 2006 @ 7:49 pm

  72. […] “…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…”read more | digg story […]

    Pingback by Nehring Nowhere » Blog Archive ReiserFS no longer default filesystem in OpenSUSE 10.2 » — October 4, 2006 @ 10:05 pm

  73. @ishmal (comment 70):

    If you’re looking to install SUSE on 20+ systems, you might want to investigate using AutoYaST to automate the installations.

    Comment by Jeff Mahoney — October 4, 2006 @ 10:17 pm

  74. I was going to post a rant…. (sigh… SUSE continues to move downhill)

    The ability to resize filesystems on the fly is an enterprise class feature. If we ditch reiserfs, we need a filesystem with that kind of capability.

    ext3 is an OLD style filesystem. I too have experienced the corruption weirdnesses with ext3 (not caused by power outs, etc). If reiserfs isn’t the right answer for SUSE, ext3 certainly is not. Unless the goal is to be just like Red Hat (which lately seems to be the goal… boggles the mind).

    This is a frustrating problem. And certainly the namesys folks aren’t helping (don’t seem to care).

    I’d think it would be wise to stick with reiserfs3 and look at what can be done to make reiser4 work.

    I mean, if we’re looking at dumping reiserfs3 for ext3, then the fact that there is not migration path directly from reiserfs3 to reiser4 is also a non issue.

    Alternatively, there’s xfs. Since jfs is a broken version of IBM’s jfs (jfs2)… not sure if it’s a viable candidate (not sure if IBM cares to help out there).

    I do not possess the skills (well.. perhaps… but certainly don’t have the time) to assess the filesystem alternatives. Just seems a shame to dump reiserfs3. When we evaluated filesystems for our large filesystems (3-5TB in size) we chose reiserfs3 combined with LVM to allow us the flexibility to grow the filesystems we use. The performance of reiserfs3 in a large scenario is pretty bad when you have to do a reiserfsck… but, even ext3 performs badly. Large file removals are slow in such a large filesystem as well using reiserfs3, but so is ext3. Obviously, reiserfs3 beats ext3 when doing file lookups. Reiserfs3 does have a problem with hash collisions (to a lesser extent so does reiser4 of course).

    This probably the worst news I’ve heard in awhile. It sounds like Novell has NOBODY on the payroll to help move SUSE forward… which is very sad (for Novell+SUSE… and me as an investor). Sigh…. very, very, very, very, very sad day. I work for an ISV (Fortune 100) and heavily influence our Linux direction. I’d hate to drop SUSE because of Novell’s lack of commitment.

    Novell needs to be involved on this… this isn’t an openSUSE decision to make. Novell needs to ensure that there is an enterprise class filesystem inside of SUSE. If that’s some modified version of ext3 (doubtful), then so be it… but somebody needs to do the work (and I don’t expect the Red Hat folks to do the work).

    Comment by Chris Cox — October 5, 2006 @ 2:18 am

  75. […] A partir do OpenSUSE 10.2 o sistema de arquivos ReiserFS n�o ser� mais o padr�o, mas sim o ext3. Os motivos alegados para a troca foram: escalabilidade, performance, pequena equipe de desenvolvimento e falta de update da vers�o 3 para a 4. Em artigo para o blog Linux do Worldpress, Jeff Mahoney apresenta mais detalhes sobre o fato… [Leia Mais] […]

    Pingback by Sometimes I dream … » Arquivo do Blog :: Blog Archive » ReiserFS & OpenSUSE — October 5, 2006 @ 6:29 pm

  76. Oh no!
    A bad new to opensource world, and a good new to Microsoft!

    But you are right, we are not married with xfs, and we must to use the best;

    Comment by dudu — October 5, 2006 @ 6:43 pm

  77. Scientific Linux is a rebuild of Red Hat Enterprise by Fermilab and CERN. They go to the trouble of building XFS back in to the Red Hat kernel because they use it in their (very, very) large storage systems. Perhaps you should contact someone on their team about it.

    I’m amazed at the plethora of horror stories about one filesystem or another corrupting peoples’ data. Personally I’ve used ext2/3, reiserfs and xfs on all sorts of linux boxes and servers for 10 years and I’ve never had a problem with any of them.

    Comment by Kludge — October 7, 2006 @ 9:19 am

  78. I started with XFS back in 2000 when SGI offered some companion boot iso’s for redhat 8 and 9. Back then I did experience some filesystem corruption. However, when XFS 1.2 and 1.3 were released for Linux I decided to give it another try and have never looked back since. I was delighted to find XFS finally integrated into the 2.6.x kernel source tree. XFS is a great choice for linux. I use it on all my systems from laptops to file servers and database servers (oracle and postgresql). It is fast, handles thousands of small files very quickly and efficiently scales to very large file system sizes and has never once failed me after the 1.3 release. I once read a comment the kernel developers made about the code being ugly. As a programmer myself who has has to maintain other people’s code I sympathize with the kernel developers if it turns out that XFS is really that difficult to maintain but I get the feeling that the code base for it has been cleaned up alot in recent years. I used to be a Fedora/Redhat fan but after the release of FC5 I could no longer use XFS as the file system for the boot partion (/boot) on linux. It was then I decided to move completely to SuSE. I currently run SuSE 10.1 on my laptop with XFS exclusively, and SuSE 9.3 on my HP X4000 workstation also with XFS exlusively. XFS is a good choice as a default filesystem for linux although I think I understand that the OpenSUSE developers want to stay with something that is more inline with the rest of the linux community. For better or for worse ext3 seems to be gaining momentum as the standard journaled filesystem on linux. As long as I can continue to use XFS if I so choose then I am ok with whatever choice they make.

    Comment by Juan Casero — October 8, 2006 @ 10:26 pm

  79. […] SUSE 10.2 Ditching ReiserFS as its’ default FS! […]

    Pingback by The Linux Action Show! Podcast » Blog Archive » The Linux Action Show! - Episode 17 - MP3 — October 9, 2006 @ 1:22 am

  80. This is amazing coincidence. I started a poll at on 28 Sept because I was having some difficulties deciding on the best fs to use, predicated by an install of openSUSE 10.2-alpha4 a few days before where I was presented with ‘rfs as the SUSE default fs.
    My knowledge of ‘rfs is that it has problems for both v3 and v4 although v3 have mostly disappeared but the SUSE choice made me look at it and others again. That led to a lot of confusion so I decided to find out what others do and, more importantly, why.

    The comments there might be helpful to you. Look here for poll and comments:
    (also, sign-up & in and vote while there! :) )

    After those comments and a few tests( ) I decided upon XFS or ext3, perhaps both.

    [extended comments]
    I am still torn between XFS which is, IMHO, a better fs than ext3 and using ext3 which provides tools for access while using that other OS. Using the extifs and/or Ext2FS program on MS OS does/will make life a little easier. Not having such access with XFS makes things harder. I know this because years back there was no access to ext2 and it always caused trouble.

    XFS can be accessed from MS OS via SAMBA, according to XFS site so using XFS does not make one completely blind unless one does not use SAMBA(I don’t at this time).

    There are issues with NFS and ext3 which, from what I can gather, involve the apparent fact that kjournald is single threaded. That does not affect me much but it does a lot of others.

    One of the issues with XFS is that one cannot shrink the fs while online. It can be expanded but shrinking requires backup, moving data, etc. Basically, formatting a new fs.

    Ext3 can shrink or grow online but honestly I don’t care. I would never trust any software to do that without backing-up all the data first. If that is going to be done(and it should be), there is no big diff between XFS shrink and ext3 shrink.

    One of the things I found here with openSUSE 10.1 is that the default setup for ext3 is type ‘news’ which are small, really small, files. The performance of ext3 is improved by using -T largefile and -O dir_index for my typical desktop usage. Using -T news is better for mail and news servers … and for that instance using a smaller block size is advised too.

    I am sure you et al will make a good choice but if it should be ext3, take some time to set it up to have reasonable defaults for desktop installs. It has been said elsewhere that using the writeback will speed up ext3. My results here indicate the opposite is true -point being don’t just take my word or anybody else’s comments as the law. Test it yourself.

    And since I have a chance, THANK YOU FOR A GREAT LINUX OS! OpenSUSE rocks …

    PS: please fix ZMD before 10.2 hits RC. Package mgmnt is really the only issue I have that keeps me from buying SUSE.

    Comment by fhj52 — October 9, 2006 @ 6:32 am

  81. Ext3 is the best choice for desktops, and its probably the best DEFAULT choice as well, given that noobs will use the defaults, while experienced users will know to pick something else if they need it.

    XFS for servers no question about it. Maybe Novell could license the tech from SGI (I bet they could use the cash) and do a native port without the translation layer.

    ps–Every Reiser3 partition I’ve ever had has eaten data.

    Comment by ehall — October 9, 2006 @ 6:49 am

  82. We shall be releasing NTFS for linux very soon - November 2006. It shall not be open-source but rather a free closed-source version that runs natively on Linux and BSDs. We at Microsoft have managed to improve the code over the years to an extent that it is now a very robust and stable file system. We hope to bring these benefits to Linux users.

    Bill Gates

    Comment by Bill Gates — October 9, 2006 @ 7:16 pm

  83. Is this really from Microsoft?

    Comment by jeff — October 9, 2006 @ 7:22 pm

  84. Must be some alien trolling the net.

    Comment by Hart — October 9, 2006 @ 7:26 pm

  85. ZFS for Linux

    Here is a link to the project: It uses the Sun CDDL license and this appears to prevent its use in Linux for anything that is linked to any GPL-based code.

    Comment by Joe Kaplenk — October 10, 2006 @ 12:41 am

  86. I am going to throw out a couple of final ideas on the off-chance that someone from Novell and/or openSUSE will read this.
    Make the change to ext3 now with openSUSE 10.2-ALPHA and study the results plus XFS(and/or other) during the next six months.


    Comment by fhj52 — October 10, 2006 @ 1:55 am

  87. Jeff M:

    That so-called ‘’ ugly Linux->IRIX compatibility layer ‘’ in XFS is surely going to be a thing of the past because SGI has pulled the plug on Irix systems and there will be no more of those systems produced by the end of this year. RE:

    The new versions of XFS are most likely going to remove the support of Irix Unix completely. Check with XFS developers but nothing else makes sense … or cents.


    Comment by rjcooks — October 10, 2006 @ 2:27 am

  88. Even if reiser4 was stable, it seems to lack quota, acls and xattr support at the moment. I’d prefer to see xfs as default choice over ext3, because it can stat() things fast.

    Comment by jengelh — October 10, 2006 @ 2:48 pm

  89. I use XFS. Only problem is that Grub does not play well with XFS - at least the version that came with Ubuntu Dapper. So I have a boot partition that runs ext3. If you don’t partition the hard drive for the user during install ext3 as default is probably the best way to go.

    Comment by rvavruch — October 10, 2006 @ 4:10 pm

  90. Think I am going to put up a poll soon on subject “preferred FS” or something like that. It will give some idea on preferences at least.

    Comment by E@zyVG — October 10, 2006 @ 4:22 pm

  91. @E@zyVG:
    There is a poll at that is running for a couple of weeks( and will run forever, AFAIK, since there is no ending date for it ):


    Comment by fhj52 — October 11, 2006 @ 1:51 am

  92. […] Diablotin: Controla las preferencias ocultas del Mac OS X MacBook Core 2 Duo en camino Confirmada la KeyNote (8 de enero 2007) Macworld Apple recluta gente para trabajar en la parte “Mobile” iPhone con posible versión móvil del Mac OS X Aumenta el rumor de un Mac portátil Links del grabador de disco duro para video de la marca LG cortesía de David Hacke Links del grabador de disco duro para video de la marca LG cortesía de David Hacke Impresora-Tostadora Las diez presentaciones más padres Proyecto E-Mexico Sitio de Palacio Postal Instituto Latinoamericano de la Comunicación Educativa Comunidad para aprender Flash basandose en videotutoriales Sitio de Emily Kim, Adobe Consultant IDE Open Source de Flex, Flash Develop Yahoo Finance (app hecha con Componentes de Charting Flex) Dashboards hecho en Flex Servidor de sockets para comunicarse con Flash y crear juegos y apps multiplayer Wii soportará Flash Buscador de código fuente Google compra Youtube Suse deja ReiserFS Científicos teletransportan dos objetos diferentes DVD Rewinder Taburete en forma de tecla 20 respuestas más usadas por los programadores […]

    Pingback by Monopolio Podcast .... el podcast más demandado — October 11, 2006 @ 6:43 am

  93. I to use xfs - for all my partition and the reason is xfsdump. No matter how stable a file system is - you might still loose all your data.

    xfsdump and xfsrestore served me well in that respect. It backups unattended in a cron job and I when the time for xfsrestore came I got my data back.

    ReiserFS does not have any dedicated backup at all and with tar/star/cpio etc. pp I allways have a bad feeling regarding my acl/xattr data. I come from OS/2 and hence I use both a lot.

    There are other goodies as well: For example online resize - need some extra data - right now - one lvm and one xfs command and 5 sec later your partition is enlarged. No umount, reboot needed.


    Comment by Martin Krischik — October 11, 2006 @ 8:53 pm

  94. I vote for msdos version 1.0, if Billy Bob will let OSS use it.

    Comment by ray — October 11, 2006 @ 10:13 pm

  95. […] Le papa du système de fichier ReiserFS mouillé dans une affaire de meurtre ?! Décidément, rien ne va plus pour Hans Reiser, depuis qu’OpenSuSE a déclaré abandonné ReiserFS pour sa future distribution. […]

    Pingback by Le Weblog de Frederic Bezies » Blog Archive » Cela faisait longtemps que j’avais pas “vrac’é” ;) — October 11, 2006 @ 11:41 pm

  96. Very bad news—

    Hans is arrested!!!!! =(

    “Hans Reiser, 42, was taken into custody at 11 a.m., hours after Oakland police and FBI technicians searched his home in the Oakland hills. His estranged wife, Nina Reiser, 31, has been missing since Sept. 3, when she dropped off the couple’s son and daughter at his home on the 6900 block of Exeter Drive… Police made the arrest based on circumstantial evidence and have not found Nina Reiser’s body, [Hans Reiser’s attorney] Du Bois said. ‘I have no idea what the circumstantial evidence is,’ he said. ‘When I hear what the evidence is against him, I’ll make a decision as to whether he’ll talk to them.’”

    Comment by Israel Cabrera — October 12, 2006 @ 12:33 am

  97. I have used for years the following filesystems

    - ReiserFS (used it over 5 years now - NEVER had any data corruption on powerfails)
    - Ext3 (used it over 3 years now - NEVER had any data corruption on powerfails)
    - XFS (installed openSUSE 10.1, power failed twice, fucked up my whole system)

    currently I’m using Ext3/ReiserFS for their robustness and stability

    ZFS is currently being ported to Linux using the FUSE framework, for more info on ZFS on Linux read Wizeman’s blog which is doing the port right now

    Comment by Grozdan — October 12, 2006 @ 2:55 am

  98. I cant believe that they would use EXT3.. EXT3 is an embarassment of a filesystem in terms of sapce and speed it just sucks period. I even see NTFS as a better filesystem. :o?

    And why are people not looking at Reiserfs 4? they don’t like Hans attitude OOOO.. WTF ? when has picking the best choice/technology been about Attitude ? ReiserFS 4 is lightyears away from other filesystems and yet we act as little kids ( it might be a greatest filesystem on earth but but.. I dont like Hans). Get a freaking GRIP !!

    If Suse goes the Red Hat way its picking the easy way out. They should stick to their guns. Stick with Reiser.

    Comment by megalex — October 13, 2006 @ 6:52 pm

  99. @ megalex

    you mean ZFS is lightyears away from other filesystems

    Comment by Grozdan — October 15, 2006 @ 8:41 am

  100. […] Esto desató una extensa polémica (y por cierto, varias bromas también) sobre el futuro de Reiser (tanto de Hans como del sistema de archivos). Que si es culpable o no, que si su empresa, llamada NameSys, seguirá mejorando y desarrollando la nueva versión de ReiserFS. Y como uno más uno es igual a tres, entre toda la maraña terminamos sabiendo que SUSE dejaría de usar Reiser por defecto en la instalación. […]

    Pingback by bootlog | loading life — October 19, 2006 @ 8:17 pm

  101. […] Esto desató una extensa polémica (y por cierto, varias bromas también) sobre el futuro de Reiser (tanto de Hans como del sistema de archivos). Que si es culpable o no, que si su empresa, llamada NameSys, seguirá mejorando y desarrollando la nueva versión de ReiserFS. Y como uno más uno es igual a tres, entre toda la maraña terminamos sabiendo que SUSE dejaría de usar Reiser por defecto en la instalación. […]

    Pingback by bootlog | loading life » BootlogFS (o el enigma de los sistemas de archivos) — October 19, 2006 @ 8:17 pm

  102. read other comments here:

    Comment by megalex — October 20, 2006 @ 7:14 pm

  103. Hmmm, its an interesting one. I have used many different filesystems, and have found ext3 the most stable, but also the slowest.
    ReiserFS is fast, but crap in a powercut, I lost the entire root partition once due to a blackout.
    XFS seems to corrupt itself, and pulling the plug out on XFS will leave you in a mess, as I proved to myself one day.
    JFS seems ok though, doesnt seem to corrupt itself or react too badly to power outages, and also its faster than ext3.
    I tend to use ReiserFS for most filesystems, but I have a UPS to stop the power outage problem… :)

    Comment by willtisdale — October 22, 2006 @ 10:37 pm

  104. @ megalex

    you can speed up your file systems you know, just add the options below to your fstab entry

    for Ext3: noatime,nodiratime,barrier=1
    for XFS: noatime,nodiratime,barrier
    for ReiserFS3: notail,noatime,nodiratime,barrier=flush

    Comment by Grozdan — October 24, 2006 @ 2:58 am

  105. […] […]

    Pingback by » Re: [CentOS] Calling All FS Fanatics - — November 3, 2006 @ 4:31 pm

  106. […] Nathan Grennan wrote: > Lamar Owen wrote: >> On Tuesday 03 October 2006 05:02, Feizhou wrote: >> >>> Suse is behind reiser v3. >>> >> >> Not any more. See >> >> for details. SuSE is going to ext3 as its default filesystem with >> 10.2, looks like. >> > I was just about to post this. It is very informative of why reiserfs is > a bad idea. […]

    Pingback by » Re: [CentOS] Calling All FS Fanatics - — November 3, 2006 @ 4:31 pm

  107. […] Lamar Owen wrote: > On Tuesday 03 October 2006 05:02, Feizhou wrote: > >> Suse is behind reiser v3. >> > > Not any more. See > > for details. SuSE is going to ext3 as its default filesystem with 10.2, > looks like. > I was just about to post this. It is very informative of why reiserfs is a bad idea. _______________________________________________ CentOS mailing list […]

    Pingback by » Re: [CentOS] Calling All FS Fanatics - — November 3, 2006 @ 4:31 pm

  108. […] Not any more. See for details. SuSE is going to ext3 as its default filesystem with 10.2, looks like. – Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 _______________________________________________ CentOS mailing list […]

    Pingback by » Re: [CentOS] Calling All FS Fanatics - — November 3, 2006 @ 4:31 pm

RSS feed for comments on this post. TrackBack URI

Leave a comment

Get a free blog at