ResierFS In Latest 2.4.1 Prepatches

Fluffy the Cat writes: "ReiserFS has appeared in the latest 2.4.1 prepatches on ftp.kernel.org. 2.4.1pre6 has a one-line error fixed in 2.4.1pre7, but it looks pretty certain that Linux will have a full jfs in 2.4.1." It will be interesting to see what's going to happen in the new development cycle, alright. The Kernel Developer Summit will have some interesting fruit, I'd wager.

Comments

Reiserfs is great.. and a warning...

[benmhall]

Hi.

I first got exposure to the Reiserfs with Mandrake 7.1. I was very impressed.

It is very fast, has been (mostly) stable and makes hard reboots very tolerable. Also, I don't tend to get the errors I would on an ext2fs, theoretically because it's journaling.

ReiserFS is a lit more than just a journaling file system though. Those interested should really check out namesys.com. They're striving for a filesystem with plugins, so it would be very extendable. Also, they way it stores information and searches is quite different.

A few words of caution though: I had major issues with a few of the bundled ReiserFS tools with the 2.4.0test series patches on my Debian Woody machine. Maybe they've stabilized since then, but I ruined my filesystem trying to fix some very odd ReiserFS related errors.

To be fair, I was running tools that clearly stated they were a last resort. When they warn you not to do something, believe it.

I am presently running 2.4.0 with the ReiserFS patch from namesys. I've been running it since 2.4.0 came out and have had no issues, but I'm still using the tools that ship with the latest 2.2.x patch, as they are more stable for me.

So, try ReiserFS, you?ll like it. Also, if you?re going to use the tools (like mkreiserfs) use the tools from the 2.2.x branch of patches. (ReiserFS version 3.5.x rather than 3.6.x) as they seem more stable..

Anyway, the end result is that my system is very stable and very fast. Having seen the obvious deficiencies with ext2 (a server at work has 100+GB of RAID Ext2fs partitions. We had an NFS bug that caused flooding and crashing a while ago. It took about 45 minutes to an hour to reboot.) the ReiserFS seems like a great improvement. I'm glad to see that it'll enter into the main kernel.

Hmm.. of course another obvious drawback with all of these new filesystems is that, to my knowledge, there are no tools for other Operating Systems to read the new filesystems. For example, you can mount ext2 partitions in BeOS, but ReiserFS is out. So, if you?re running multiple OSs then you may want to keep at least one ext2 or maybe a FAT32 partition.

Hope this helps,

Ben

More info

[autocracy]

First off, the Reiser File System is what we call a journaling file system. That means that as something is about to be written to the disk, another item describing what is about to be done is written to the disk first (the journal). Now, if you system crashes while the journal is being written, that's no big deal for the filesystem: whatever you were going to save/delete just doesn't get done and the computer happily moves on. However, if your computer crashes after the journal has been written and you're saving that special file, the systems looks at the journal on boot and says "oops, this didn't get done - let's throw it out." Obviously you lose your file here, but it's no worse than in a non-journaling system. In one of those you lose your file, corrupt your filesystem, and lose your data anyway.

For further details on Reiser FS, check out this page. Freshmeat links to it, but I'm not entirely certain it works (I can't bring it up from here).

Also note that the maker of the file system, Hans Reiser, is suing Microsoft for the information that he needs to market the filesystem to Windows users :)

My karma's bigger than yours!

Stable

[chrisdb]

Will the version included in 2.4.1 be labelled as stable or expirimental ?... I've seem numerous posts on BugTraq lately concerning ReiserFS.

Futhermore i've read somewhere "don't use the filesystem on systems which allow 'average' users to access the reiserfs-filesystem". Can anyone tell me what they mean by this ?.. is it 'not safe' or what ?...

Re:Rock Solid

[Psiren]

But then why should I backup my data ?

Because not doing so is the metaphorical equivalent of flopping your wedding tackle into a lions mouth and flicking his love-spuds with a wet towel. Total insanity! ;-)

Shamelessly stolen from Red Dwarf, but an apt quote. If you're going to mess with your filesystems, back them up. Nuff said.

Linus is violating his own submission policy ....

[geirt]

This was sendt to the kernel list a week ago by Linus: http://www.uwsg.indiana.edu/hypermail/linux/kernel /0101.0/1192.html

This is the interesting part:

I thought I'd mention the policy for 2.4.x patches so that nobody gets confused about these things. In some cases people seem to think that "since 2.4.x is out now, we can relax, go party, and generally goof off".

Not so.

The linux kernel has had an interesting release pattern: usually the .0 release was actually fairly good (there's almost always _something_ stupid, but on the whole not really horrible). And every single time so far, .1 has been worse. It usually takes until something like .5 until it has caught up and surpassed the stability of .0 again.

Why? Because there are a lot of pent-up patches waiting for inclusion, that didn't get through the "we need to get a release out, that patch can wait" filter. So early on in the stable tree, some of those patches make it. And it turns out to be a bad idea.

In an effort to avoid this mess this time, I have two guidelines:

- I've basically thrown away all patches sent to me so far, and I will continue to do so at least over the weekend. I'm not going to bother thinking about patches for a few days.

- In order for a patch to be accepted, it needs to be accompanied by some pretty strong arguments for the fact that not only is it really fixing bugs, but that those bugs are _serious_ and can cause real problems.

Obviously, the size of the patch matters too: if you can make an obvious fix in 5 lines, do it. Don't try to make a clean fix that fixes the problem the clever way in 150 lines.

In short, releasing 2.4.0 does not open up the floor to just about anything. In fact, to some degree it will probably make patches _less_ likely to be accepted than before, at least for a while. I want to be absolutely convicned that the basic 2.4.x infrastructure is solid as a rock before starting to accept more involved patches.

Re:Other Journalling FS

[Anonymous Coward]

For comparision of JFS, XFS, Ext3, and ReiserFs see http://www.linuxgazette.com/issue55/florido.html

Re:Vulnerability in ReiserFS

[Azog]

Don't panic. Don't spread FUD. This has been worked around in the latest prereleases from Alan Cox. A hard limit on the length of filenames has been set as a temporary fix.

Many people on the linux kernel mailing list could never reproduce it anyway.

At any rate, the issue is being studied and a better fix is "coming soon". You can be sure that by the time there's a real 2.4.1 that the problem will have been solved.


Torrey Hoffman (Azog)

SGI's XFS rocks as well

[FreeUser]

I am using reiser at work (and quite like it for some things), but have recently begun experimenting with SGI's xfs filesystem as well, and must say that thus far I am very, very impressed.

So impressed that, at home, I have migrated from reiserfs (the reiser 2.4.0 patch and the XFS cvs tree wouldn't coexist, though that will probably change now that reiser is in the official tree). For the video editing I'm doing XFS works very well, and the scalability is astounding!

The only thing that worries me is that SGI has commented that they "won't support competing standards" (paraphrased) if the community chooses something other than their work. While I applaud this stance in principle, I think for filesystems it is very misguided. Linux is designed to support a choice of many filesystem types, and it would be very unfortunate indeed if XFS were not among those choices. Reiser is great, ext3, JFS, etc. are probably fine, and XFS (even in beta form) is just plain awesome.

If anyone from SGI should be reading this, I hope you will not construe the inclusion of reiserfs in the official kernel tree to mean the community "has decided" on a standard, and that even if the community had, that work on XFS will continue. Hopefully, when it comes to chocies like which filesystem one prefers, there will never be a "standard," but rather a standard set of choices which will include ext2, xfs, reiser, and perhaps in the not too distant future one or two encrypted filesystems as well.

Re:Stable - Root Partition Howto

[leistnerm]

Here is a pretty good howto for moving your root partition to ReiserFS. I used it a while ago, and haven't had any problems since then. ReiserFS seems to run a little faster, and the short fsck times are definetly nice. http://kurt.andover.net/Reiser-filesystem-HOWTO.ht ml

Linux kernel vulnerability exposed by ReiserFS

[Mr Z]

There's a vulnerability in Linux with long directory names that's exposed by ReiserFS. As best as they can tell, the vulnerability is in the Linux VFS layer, and not ReiserFS itself. See this page and this page for more details.

As for whether this makes the FS marked experimental or stable, I don't know. I'd imagine that it'll be marked experimental simply because this is the first mainline release to include it.

--Joe
--