Novell Moves Away From ReiserFS 404
VSquared56 writes, "Novell announced a shift in the default filesystem from ReiserFS to ext3 for users of its SuSE Enterprise Linux. This news comes shortly after Hans Reiser's arrest, though Novell says the decision was being considered long before. Though Novell will continue supporting ReiserFS 3, it claims ext3 is more stable and will 'soon' match performance with the newer ReiserFS 4. What implications will this have for SuSE users, and ReiserFS's future as a whole?"
Old news (Score:5, Informative)
It's also interesting how people now explain the blood on Reiser's shirt in this comic [geekz.co.uk], while this comic also predates this whole arrest story.
Nothing todo with Hans' arrest. (Score:5, Informative)
Smart move, just a little late (Score:5, Informative)
First your average backup. Yes, I'm well aware that you can always tools like tar but really.. Its the same deal with Sun's current development ZFS: it lacks the option to decently make a backup. Yes you can use tar, but I don't consider this decent. I'm talking about tools like backup/restore (ext3) or even native "ports" like xfsdump/xfsrestore. Easy, fast and reliable. Make a whole dump (or increamental), you can then either restore the whole session or use an interactive shell to merely grab the file(s) you're after. Naturally it also supports commandline parameters. And Reiser? IIRC (correct me if I'm wrong please) its even longer around than xfs, and even xfs managed to get me something decent for making backups...
Last but not least; crash recovery. I know, this is threading on thin ice since these results cannot be reproduced perse but the whole nature of reiser makes it good and bad for workstations (like SuSE). The good part is its speed, the way it caches and writes data in such a way where it tries to store things in one specific part makes it faster. I can't comment if reiser really is faster than others, I never noticed it. But the bad part is also that if you have a crash on your hands (just turn of your computer right now. No, not a shutdown but keep the powerbutton pressed untill it goes "poof") and reboot chances are very high that you just lost valuable data.
The theory behind journaling should give you some protection against this, and normally it does, but its my experience that whenever something like this happened on a box which was using reiser I lost just too many files. Several files in
Eventually I moved to XFS myself and never bothered looking back. Its not perfect, absolutely not since on XFS you too can experience situations like I just described. But in that same environment where I sometimes had to endure a powerloss I noticed that the frequency in which my data became corrupt was far and far less than with reiser. So my conclusion: reiser isn't the best when it comes to keeping your data safe. Its also a conclusion which has been backed up by other people who experiences the same problems in a more or lesser degree.
So my comment: finally Novell is coming to its senses. IMO they should have done this years ago, either going to XFS (my favorite) or ext3 where the latter is ofcourse the most logical choice considering how this evolved from ext2 (which, strangely enough, used to be the default on SuSE. I never did understand why they'd move away from it).
Thins aren't looking up for Hans. (Score:5, Informative)
If he were a famous football player, he'd have a chance, but I don't think a filesystem developer can muster up a "dream team".
I expect other distros will knee-jerk too.
$ mount
Re:Rats first and Captain last (Score:5, Informative)
Just BTW, I am using reiserfs3 on my system and I thinking about migration to some FS with future.
Hard to Believe (Score:5, Informative)
Re:xfs for ever (Score:3, Informative)
For example:
# smartctl -A
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail Always - 0
This disk hasn't yet had any bad blocks. As the disk ages and blocks go bad, RAW_VALUE will go up, and VALUE will go down. When VALUE <= THRESHOLD then there are no more spare blocks and bad block errors will be reported to the operating system. At this point the disk should be replaced.
Re:xfs for ever (Score:4, Informative)
So you pop the power off and *wham* bye bye cached data. This is definately not any kind of fun.
XFS was written for environments where the power just dooes not go out -- datacenters, people with a very good UPS etc. I generally recommend XFS for people with lots of large files, but if they don't have a good power backup, I change my mind.
Re:xfs for ever (Score:5, Informative)
No, this happens because it's the way XFS does journalling.
XFS journalling isn't as good as the one in ext3, from users' POV. Ext3 default journaling mode takes care of the relationship between metadata and the data associated to that metadata (and here let me remember that journalling/softupdates is a way to avoid corruption of the *metadata*, if you lose data because of a power cut that's fine, but it's not fine that the filesystem gets damaged and needs fsck because the metadata got corrupted)
IOW: when ext3 is going to write metadata to the disk, it looks first to the dirty data cached in the memory and writtes the data *before* it writes the metadata.
XFS journaling, in the other hand, does *not* care about writing the data before the metadata. Why? Well, because journalling is about keeping the metadata safe so you don't need fsck. This means that in case of a power cut, XFS may leave the contents of a "file" (metadata) unscycrhonized with its data. Because of that, the metadata may be pointing to random free zone of the disc with confidential information (passwords) which was deleted but it has not been overwritten, so XFS sets it to zero for safety. Ext3, on the other hand, will never left your data "unscychornised" with your metadata. The file may get corrupted because the program that was manipulating it was stopped in the power cut, but the relationship between the data and the metadata is always coherent.
Ext3 journaling mode may be considered an "extra", and it *does* pay a performance disadvantage because of this. If you want ext3 to behave like xfs (and get better performance), mount your fs with the mount option "data=writeback". Reiserfs in the other hand historically had a similar journaling method as XFS (just like JFS), but the suse guys created a journaling mode similar to the default one in ext3 which AFAIK is not enabled by default (at least on mainline) and gets enabled with "data=ordered"
Is the XFS journaling mode worse? Well, for desktop users, who would rather have syncronized their data and their metadata, clearly yes. This is why XFS is just not the best FS for desktops - its a wonderful FS, but just not "optimized" for desktops. NTFS journaling does the same that ext3 does, BTW, and it's for a reason.
Re:xfs for ever (Score:1, Informative)
My trust in ext3 is so low that it can't be reestablished. That two of my friends have had the same problem with ext3 and never with reiserfs doesn't help me getting more confidence in ext3.
From the Horse's Mouth (Score:5, Informative)
1) The decision has *nothing* to do with Hans' situation. The email was released on the same day as the initial story broke, but it was pointed out to me after I had sent the email. I was concerned then, correctly as it turns out, that people would consider the two issues intertwined. They're not. My proposal was based on technical and maintainability reasons alone. The timing is an extremely unfortunate coincidence.
2) SUSE is *not* dropping reiser3 support. This change only affects the default. It doesn't change our support of reiser3 at all. We still support four major file systems: ext3, reiserfs, xfs, and ocfs2. Our installer offers other file systems as well as a convenience, and users are free to use any of them. So, if you're committed to reiser3 or xfs, nothing is stopping you from continuing to deploy systems using them.
3) Many benchmarks show reiser3 as performing better than ext3, and this is mostly true. What isn't shown in those benchmarks is that if you're operating two or more reiser3 file systems in parallel, performance will degrade for both of them due to the use of BKL everywhere. ext3 (and other file systems) will don't degrade in that case. I've also read reports that there is a bit of research going on into making ext3 locking finer grained. I don't have any sources to cite, but any reduction of critical sections without reducing reliability is always a good thing.
People refer to reiser3 as a modern file system, but I'd call it progressive. Reiser3 has served us well for years, but it's showing its age. The basic idea behind reiser3 is still sound, and when extended with integrated integrity checking and better b-tree locking borrowed from years of database research, it would perform extremely well. The problem is that adding the first is a huge disk format change, which means it's no longer reiser3. Adding the second is a hugely invasive change that would throw out a good chunk of the existing code -- again, essentially creating a new file system. It would be like people saying, "I like my ext3 file system, but I don't like the code. Let's start over." Combined with a small development community, it's a recipe for instability and there are more interesting problems out there.
I've posted some more lengthy comments here: http://linux.wordpress.com/2006/09/27/suse-102-di
RTFM (Score:4, Informative)
See Solaris ZFS Administration Guide, Chapter 6 Working With ZFS Snapshots and Clones [sun.com].
Re:xfs for ever (Score:3, Informative)
The UPS covers the power line problems, which are the leading cause of system outages. To protect against the less frequent hardware failures you need properly engineered redundancy for every critical component. That's why "enterprise-class" data storage costs so much more per GB than the disk drives on sale at retail store. An alternative is to not use any write-behind caching. The performance loss varies, depending on the write/read ratio. The average desktop system doesn't gain much performance from write caching, because the most time consuming disk activity is loading multi-megabyte executables and existing data files, not writing and updating files. That also means they're at less risk in any case, because there is less unwritten data in the cache to cause problems. An online transaction system, on the other hand, does continuous file updates and little application loading. These need professional quality hardware (and software!) to deliver the expected level of reliability.
Re:You're forgetting (Score:3, Informative)
Turn in your nerd license, that's not how the defense works. Here's how:
"Ladies and gentlemen of the jury, this is Chewbacca. Chewbacca is a wookie from the planet Kashyyyk. But Chewbacca lives on the planet Endor. Now think about that; that does not make sense. Why would a wookie, an 8 foot tall wookie, want to live on Endor with a bunch of two foot tall ewoks? That does not make sense! But more importantly, you have to ask yourself, 'what does that have to do with this case?' Nothing. Ladies and Gentlemen, it has nothing to do with this case. It does not make sense!"
Re:ext3 more reliable? Whatthe! (Score:3, Informative)
Re:xfs for ever (Score:3, Informative)
Re:The Slashdot Way... (Score:3, Informative)
Regardless of what you think about him personally, it's hard to dispute that he's an "actual programmer".
Re:ext3 to match ReiserFS 4? (Score:3, Informative)
Ext(2/3) use a traditional UNIX FS design and most software has been written to work acceptably on this type of file systems. In other words, nobody writes software that creates thousands to millions of tiny files because ext absolutely sucks at this (and ext4 doesn't help much) . So to get around this most of today's software create a new namespace in a single file.
reiser(fs/4) also use extents which improves its handling of really large files which is becoming more common (movies, music, etc.). ext4 introduces this feature.
So for today's common usage patterns and file sizes ext4 will perform reasonably well compared to reiser4.
But if you where to extend fs semantics enough to make it reasonable to use the fs to directly back something like gconf (http://en.wikipedia.org/wiki/GConf [wikipedia.org]), reiser4 would be substantially (10x) faster than ext(2,3,4) could ever hope to be. In principal if you extend the filesystem to directly support gconf and similar you would be able use of many fs tools for free.
Consider the windows registry. It is a mistake because it obscures the information by its convoluted structure and just as significantly, one can't use all those usefull tools on the registry you use with your file system (well not to many in Windows). Gconf addresses the first problem but not the second. Overall, I would consider the
Yet, the windows registry had the good idea of creating a consistent way to store the the same type of data. Saving programming time and building a single consistent source for all things configuration. I believe it is possible to build something that gets the best of
The more use one can get out of a tool, the more people will work to develop and improve it. By using the same namespace for as much as possible, the more value a tool designed to work with that namespace will have. In other words, the utility of a computer system is proportional to the number of ways the components can interact, not the number of components.
To achieve this objective, one needs a solid foundation, a system that can efficiently store whatever you ask of it, that is what reiser4 is trying to be. But, clearly much work remains.
Re:No one laughed last time... (Score:3, Informative)
I can relate (Score:4, Informative)
Resierfs looked like the clear winner for two good reasons:
1. Reiserfs is faster. Much faster than ext3 in nearly every scenario. Large files and small files.
2. No inode problems. If your users fill your HD with hundreds of thousands of tiny files you're not going to run out of inodes before you run out of disk space. This is something that needs to be anticipated (at the cost of more disk space) at filesystem creation time in ext3.
Reliability for both filesystems was pretty much the same from all accounts.
But in the end I went with ext3 for one and only one reason: Recoverability.
Reiserfs had no, or very few decent, recovery utilities. If a filesystem corruption occurred (and it seemed that the probablity of such corruptions was equal for both filesystems), then data on an ext3 fs stands a much better chance of being recovered than on a reiserfs one.
Of course that was late 2005; that situation may have changed by now.
Re:xfs for ever (Score:3, Informative)
Not so:
XFS: 1994 (IRIX 5.3 XFS)
JSF: 1999 (OS/2 Warp)
ReiserFS: 2001 (Linux 2.4.14)