Slashdot Mirror
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.
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
On ext2, I see slightly faster (~10%) on per character io, and significantly faster (30-50%) on block io.
This is on the same partition on the same disk. The reiser page, of course, says how much faster it is than ext2, but I can't verify that. Has anyone else seen anything similar? I recently read a review of reiser that came up with the same results... although I can't find that review now.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
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!
SIG: HUP
You've say that XFS is very impressive, and that you've switched from ReiserFS to XFS.
:)
Can you elaborate as to why you switched, using quantitative data? Does XFS boot faster after a crash? Does it require less memory? Is it faster for n-sized files? Is it faster for n-way SMP systems? Is it more secure, more reliable? Do you have any repeatable benchmarks?
Inquiring minds want to know
-OT
features: well, it's fast, especially in edge cases like many thousands of files in a directory, where ext2 has trouble. Transaction support is coming too, which could be pretty neat. The speed used to be better than ext2, and is now slightly worse (pretty good for journalling), and will probably improve once a stable point is reached and some energy is spent reoptimizing.
32k subdirs: no, I don't believe that limitation exists. Most every limit of that sort has been pushed out to 2**32 or 2**64. I'm not sure I'm remembering properly, though.
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 ?...
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.
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.
RFC1925
Background: One of the benifits of a jfs is being able to 'roll-back' changes or to select a specific revision without rolling back the current version.
Q. What file systems are available that can do this, and what tools are available to get back intermediate revisions of a specific file or directory tree.
With cheap disk space, this looks like it would be a great tool to have, while faster boot time is less valuable unless you are running a time critical application and any delay is a bad thing.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
For comparision of JFS, XFS, Ext3, and ReiserFs see http://www.linuxgazette.com/issue55/florido.html
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)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
This bug has been fixed.
x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxx': File name too long
I've you actually followed reiserfs development any you would know this. The issue was the fact that reiserfs knows how to handle filenames longer that 255, but the VFS in the linux kernel does not. So, reiserfs that is in 2.4.1-pre7 limits this to 255 characters..
As proof for you tiny little mind...
mkdir "$(perl -e 'print "x" x 768')"
mkdir: cannot create directory `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The said filesystem is reiserfs..
You don't seem to hear much about the other journalling filesystems, most notably JFS and ext3. I would really like to see an article comparing the different filesystems ... including a walkthrough of patching the kernel, making the filesystem, etc ... perhaps I'll do one up this weekend.
RFC2119
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.
The Future of Human Evolution: Autonomy
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
www.namesys.com
This is why linux has not been the enterprise choice; when it costs you x thousand dollars for a minute of downtime, you want that server back up as quickly as possible. Now we just have to have the FS war; ext3, reiser, jfs, xfs....:)
--
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--
Program Intellivision!