ResierFS In Latest 2.4.1 Prepatches 181
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.
Charon (Score:1)
Re:Stable (Score:2)
Reiserfs is great.. and a warning... (Score:5)
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
Re:Hans Reiser - the next Einstein (Score:2)
How do I get started (Score:1)
Re:Bad inodes with reiser/NFSv3 (Score:1)
Re:Very good news (Score:1)
#
3105046413
All vxfs, of course.
Re:Rock Solid (Score:2)
I have 30 gigs on this machine alone, but I manage to fit everything that's important onto a single 15 gig DLT tape (and a few unimportant partitions because they'll fit.)
Use some common sense; not all 80 gigs are worth backing up.
- A.P.
--
* CmdrTaco is an idiot.
thinking ahead. (Score:1)
Re:Software RAID + ReiserFS (Score:1)
YMMV, of course. I'm using LVM with striping, so this isn't technically RAID - what you refer to is most likely the linux md device with the raid personalities. However, I'm betting the same idea applies, as you should be able to put whatever filesystem you want on a logical volume.
Hint: try Lilo 21.6 (Score:2)
The rationale is that Reiserfs packs tails (fragments) unless you give it the notail mount option. If your /boot directory is on a
Reiserfs, it should be
mounted notail if you don't have Lilo 21.6 (which does understand Reiser tails).
(if using notail, add it to the mount options in /etc/fstab for whatever file system /boot is located on.)
Off topic? (was Re:HAH-hah!) (Score:1)
Re:HAH-hah! (Score:1)
Re:Stable - Root Partition Howto (Score:1)
Re:What else besides fsck? (Score:1)
reiserfsck
Re:Stable - Root Partition Howto (Score:1)
"Homo sum: humani nil a me alienum puto"
(I am a man: nothing human is alien to me)
Re:More info (Score:1)
OK, I understand that. But that being the case, how can it possibly by 15% faster than ext2 as people are claiming here. Are there that many inefficiencies in ext2 that are resolved in reiserfs?
I thought I remember reading that NTFS was slower than FAT32 because it used journalling. Is that the case? Is it at all relevant? Will I ever stop asking questions?
Re:Stable (Score:1)
"Homo sum: humani nil a me alienum puto"
(I am a man: nothing human is alien to me)
Re:Distributions? (Score:1)
Poor Reiser performance? (Score:3)
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.
It wasn't me, honest! (Score:2)
Because I never kick out power cables. Instead I compulsively flick those huge red switches you find in IT operations rooms.
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....:)
It's an imporatant corner stone, certainly. Like better SMP support and the LVM. On a cached (by the OS) disk sub system you don't want to install a productive database device on a file system.
But the real reason of course, is that the decision makers (senior management) don't have clippy, the paper clip which should be shot at their disposal.
Good Experiences for Me (Score:2)
It's great for my purposes, but it's not a true journaling filesystem, it simply journals metadata, which, while allowing for fast fscks, it doesn't protect your data as well as IBM's filesystem or SGI's will.
Re:About time! (Score:1)
Re:Yes! (Score:2)
> wow, something ever other OS has had for years
Huh ? Since when windows 95/95 have a journalling FS ? Since when Mac OS have a journalling FS ? Since when NeXTstep/OPENSTEP/Mac OS X Server have a journalling file system ? Or Mac OS X ?
> Now maybe Linux can get a user-friendly GUI?
OSes with a user-friendly GUI and a journalling filesystem are BeOS and WinNT/Win2K.
Cheers,
--fred
More info (Score:5)
For further details on Reiser FS, check out this page [devlinux.com]. 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!
Re:Yes! (Score:2)
Re:Reiserfs is great.. and a warning... (Score:2)
Although this opens a lot of possibilities it could also be rather dangerous. As long those plugins cannot mess with the core of the file system, I don't see much of a problem.
Illustra (bought by Informix [informix.com] a few years ago) had the conceptual great idea of Data Blades. Those where modules (plugins) you could write yourself to add additional functionality to the database engine and that there are a lot of rotten programmers out there.
I don't know, if this is still an issue. But a few years ago you had to have your Data Blades certified by Informix, otherwise a voided warranty (probably in terms of support) might have been the least of your worries.
Thanks for your interesting post.
fsck? (Score:2)
--
Re:Some thoughts. (Score:2)
The ReiserFS developers had been tracking 2.3.x kernels for quite a while; they were in the process of auditing the interfaces to the VFS layer at the time that 2.3.x got "frozen" in preparation for release of 2.4.
The fact that this took place rather a long time ago and that there were a serious lot of "pre-2.4.0" versions is a conspicuous fact.
As for the "fighting," it was resolved in two directions:
It should be noted that "vigorous flaming" does not necessarily indicate personal acrimony; there are rather a lot of "spirited words" said around the kernel lists that really are technical comments. If someone thinks that some particular code is severely braindamaged, there is no fear of saying so. If the author, or someone else, fixes it, that's well and fine and may result in the inclusion of what used to be "braindamaged."
The complexity of the sizable and steadily growing group of "competing interests" in the Linux kernel is certainly making it more difficult over time to do major releases. If the process gets much more difficult, that's the sort of thing that is liable to result either in fragmentation or in people deciding to jump over to one of the BSDs or perhaps even to Hurd. Not that that those directions are likely tremendously relevant to the deployment of ReiserFS...
All in the Settings and Needs (Score:1)
I used to have reiserfs with notail, nolog and noatime mount options on my Squid cache partitions for extra speed, and the fact that in the event of a crash the system could easily mkreiserfs instead of fsck, because Squid cache data isn't very important to keep. The system did so only once, due to the cable technician tripping over the power chord.
Back then I did benchmarks using simulated Squid test loads on ext2 vs reiserfs with and without journalling enabled. Of course journalling disabled was clearly faster than ext2, but reiser journalling enabled was not statistically different from ext2 in several test runs. It might be something about the nature of squid cache files.
Now I no longer run a Squid server, but I believe they added another mount option specifically for additional Squid performance which does away with filenames. (Not sure about this.)
As for non-Squid server usage, it would be dumb to not activate journalling if your data is important to you. reiserfsck has been somewhat lacking in the ability to fix corrupted filesystems.
Bottom line - Journalling is good. Save hours of fsck time, get your enterprise servers back up quickly and save your job. I'd say that's well worth a negligible performance hit for most servers.
Re:Poor Reiser performance? (Score:1)
XFS - another link (Score:2)
Re:Linus is violating his own submission policy .. (Score:2)
You all try to explain why it's okay that Linus allowed ReiserFS into the 2.4.1-pre series, and whether or not he violated his own submission policy. I'll tell you why it doesn't matter one way or the other:
IT'S LINUS'S FUCKING KERNEL. One of the best perks of building your own operating system kernel is the ability to set policy as you see fit. If he sets a no-submission policy, and then allows Hans Reiser's patches into the kernel, his policy is now to only allow Hans Reiser to submit patches. It may change tomorrow. Why you gripe about his conformance to his own policy is beyond me. You shouldn't care what Linus does with his kernel, it's his; you don't have to use it if you don't like it.
Oh, and to back up another correspondent in this thread, indeed, Linus did announce plans to include ReiserFS in 2.4.1 long ago, in an online interview. Or maybe it was print. But I saw it. In fact, everybody has been saying ReiserFS would make it into 2.4.1 for a long time.
PS -- No doubt, in an attempt to attack me, someone will tell me it should be "Linus'" instead of "Linus's"... but no, the apostrophe-s belongs there. If you disagree, I urge you to consult the fabulous writing handbook Elements of Style by White. At least, I think it's White... but the title is certainly correct.
A new year calls for a new signature.
Re:More info (Score:2)
For large directories with a lot of files, this decreases the number of inode pages which are necessary to lookup a particular file. For smaller directories, it results in a logn lookup in memory (becuase the individual inode pages can be binary searched).
Finally, journaling of the ReiserFS form results in a speedup becuase it can write the bigger inode block at some point in the future.
NTFS was at least partially slower becuase the first version used a transactional scheme, which always introduces overhead. I don't know much more, but I know that at least the tree-structure for inodes in ReiserFS is responsible for quite a bit of the help. Our builds were 15% faster (becuase all that dependency checking hits the FS itself hard, much more than the disk itself).
Re:Vulnerability in ReiserFS (Score:1)
But, when I made two such directories inside each other and CDed into the last, the path returned by pwd got chopped to only the last directory, since paths can't be more than 4096 characters long, AFAIK.
© 2000 Ilmari. All ritghts reserved, all wrongs reversed
Yes! (Score:1)
-stax
Data Blades a Pretty Good Analogy (Score:2)
In the 'real world' we see that there aren't a whole vastly lot of manufacturers of knives; while there are a bunch, it doesn't tend to be something that just everyone does. I don't make knives; I buy them.
Heading the point towards ReiserFS, it seems unlikely to me that everyone will be writing "plugins" for ReiserFS. In practice, there will be a few important plugins that will get looked at pretty carefully before deployment:
In much the way that writing kernel code is less convenient than writing user space code, due to the lack of many of the Standard C Library services that people expect to find, writing ReiserFS plugins is likely to be sufficiently "inconvenient" as to discourage "just any moron" from widespread deployment of oddball plugins.
Re:Very good news (Score:1)
p.s. My sig is totally and utterly out of date
--
Azrael - The Angel of Death
posted with: Mozilla (0.7)
Re:Linus is violating his own submission policy .. (Score:1)
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.
Uh. Yeah. Promote dirty hacks. Please.
Re:Hopefully so (was: Very good news) (Score:2)
My recipe for disaster was to have a really big benchmark running.
Can you elaborate? (Score:3)
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
Re:What else besides fsck? (Score:3)
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.
Stable (Score:4)
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 ?...
A bit of overstatement... (Score:2)
The more usual literature on "namespaces" can be found discussed with The Use of Name Spaces in Plan 9. [bell-labs.com] That's actually a quite useful/relevant thing that would represent a really cool thing to add to Linux in the future.
The critical extension is that rather than mount being associated with a "global" filesystem space, where all mounted FSes are associated with /etc/mtab it is associated with a particular hierarchy of processes.
Thus, my user ID might mount a DBM file via something analagous to mount -t dbm /home/cbbrowne/data/something.dbm /n/something ; that presents the DBM file in some sort of filesystem mode under /n/something . Unlike traditional mounting:
Alex Viro has occasionally commented on this being a potential neat thing to add to Linux; that's what would make "namespaces" really cool and useful; I don't see it happening 'til Linux 2.7, and it absolutely should not have anything to do with a particular filesystem implementation.
Bearing? (Score:1)
Software RAID + ReiserFS (Score:1)
Great news (Score:1)
Nice to have (Score:1)
HAH-hah! (Score:1)
Okay, okay, this is good and bad. At least Linus and the others are still ironing out the kinks in the kernel, but come on, wasn't it supposed to work right the first time?
Re:Very good news (Score:1)
x86 only... (Score:2)
I hope so... fsck on my SMP Sparc 10 box can be a slow process. The 2.2.18 patch is forgets to do a #define in errno.h and the utilities that come with it Bus error.
Brian Macy
Re:Other Journalling FS (Score:1)
ext2 is proven code. reiserFS just isn't as proven.
The big question is whether the additional integrity reiserFS gains from journalling outweighs its lack of stress testing.
Currently, I'm still more comfortable with ext2, but reiserFS is rapidly catching up. I figure I'll let another 100000 kids on the block install it first, and if they survive, I'll join too.
The thin layer approach wins in this situation -- your distate aside -- as it is easier to prove to yourself that you aren't violating the proven code's assumptions in the thin layer than it is to prove that you've successfully re-implemented the stability in a new architecture.
Eventually we do need to re-architect, but those re-implementation are to be viewed with extreme suspicion. So I'm paranoid, but I don't have any backups.
My only problem with ReiserFS (Score:1)
Re:Hopefully so (was: Very good news) (Score:1)
Re:UFS? (Score:1)
Re:Stable (Score:2)
Here's a testimonial from namesys [namesys.com] web site that helped to convince me:
http://ftp.sourceforge.net/ has 850GB storage, half of which is reiserfs, half is ext2. Both filesystems have been running flawlessly for > 4 months of production (actually longer, but wasn't reiserfs before). That server pushes between 15Mbit and 50Mbit/sec, and pulls/syncs about 2-5Mbit/sec, 24x7.
reiserfs also powers the CVS tree filesystem for cvs-mirror.mozilla.org (also tokyojoe.sourceforge.net), which is the one and only anonymous CVS checkout point for mozilla. That server has run flawlessly under very heavy load since its birth.
Does max file size of 2gig still apply? (Score:2)
My HP-UX systems at work have Oracle datafiles in the 10gig range.
I want to set Linux up as a standby server with identical data files, just to compare performance, but this can't be done on stock ext2, which enforces a 2gig limit on file size.
I hope ReiserFS fixes this.
Are you using disksuite? (Score:2)
Is the ability to mount with journaling introduced when you install Solstice Disksuite, or do you get that ability when loading the plain vanilla Solaris 8?
If you had to load Disksuite, did you have to load a new kernel, or did it just throw on some modules?
Pardon the questions of a Solaris neophyte. I guess I should check the man pages.
Re:Other Journalling FS (Score:2)
Re:Rock Solid (Score:4)
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 .... (Score:4)
This was sendt to the kernel list a week ago by Linus: http://www.uwsg.indiana.edu/hypermail/linux/kernel /0101.0/1192.html [indiana.edu]
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:Stable (Score:2)
Dumb questions: Rolling back changes (Score:3)
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.
Does it work with LILO yet? (Score:2)
Re:SGI's XFS rocks as well (Score:2)
I had the same thing happen, where a root partition filled up with invisible data no files could account for, until a reinstall was required. XFS, in contrast, has never suffered from this. While XFS is beta, I have found it to be better behaved than reiser in this respect, and rock solid thus far.
Don't get me wrong, I like both reiser and XFS (haven't tried ext3 yet), but why reiser should make it into the kernel and XFS not, given my personal experiences which would indicate that, if anything, the opposite order of inclusion would have been more warranted, is beyond me.
There must be other technical and/or political issues involved of which I am unaware. It is, however, no big deal, since the XFS CVS tree is simple enough to download and works great, so while it is less convinient than having it in the official tree would be, and arguably unfair, the decision by no means denies me my own freedom of choice, which, in the end, is what running Linux is all about.
Some thoughts. (Score:2)
However, I would like to throw in some points:
ReiserFS is superb code, IMHO, and provides a much-needed journalling file-system to the kernel. But the timing is not good. By now, the series should have reached a hard freeze, to start moving into production code. But this is a BIG change, suggesting that 2.4.x is really a slushy 2.3.x that's been bumped up early.
Now, it's arguable that ReiserFS has received plenty of testing, is a good system, et al, all of which is true. I won't dispute any of that. My concern is that it should have gone in much sooner (at the latest, in the 2.4.0pre stage, to iron things out), as waiting until 2.5 is a bit stupid.
By adding it now, though, the precident has been set. Development code CAN be added to the Stable series, with the inevitable consequence that Linus is going to get a battering from wannabe kernel hackers.
Rule #1: Once you start paying Dane Gold, expect to keep on paying. It won't get any better, if you go down that road.
Re:Software RAID + ReiserFS (Score:2)
on the other hand, I haven't read about it anywhere, so I wouldn't try on, say, my mission critical corporate server.
Re:Other Journalling FS (Score:4)
New ReiserFS tools now available. (Score:2)
Ok, here is reiserfs utils directory for linux-2.4.1-pre7
ftp://ftp.reiserfs.org/pub/2.4/linux-2.4.1-pre7-r
To use it just put the patch in "linux/../" directory with pure linux-2.4.1-pre7 and :
# bzcat linux-2.4.1-pre7-reiserfs-utils-patch.bz2 | patch -p0
Also, there is a patch to fs/super.c which you should apply if you are using ReiserFS for a root filesystem.
You can see the message and the patch here:
http://marc.theaimsgroup.com/?l=reiserfs&m=9796521 9413577&w=2
Re:Does it work with LILO yet? (Score:2)
I know for sure that there are atleast patches to LILO to get it to work with ReiserFS, however LILO I don't think is the optimal solution.
I've been running ReiserFS for some time now, and during my switch to it I also switched boot loaders to GRUB [gnu.org] which seems like an overall better bootloader. I can tell you right now that the GRUB command shell has saved me a few times already.
-- iCEBaLM
Great! (Score:2)
Re:Large root partitions(was: Re:Very good news) (Score:2)
With the new lilo (or if you prefer the grub) you can boot from any cylinder so you don't need separate
I've been using ReiserFS that comes with Mandrake 7.2 for three months now both with 2.2.17/18 and 2.4pre-sthg, now stable. My only concern was that I wasn't able to use a standard kernel. Now I can't wait for 2.4.1.
Re:Other Journalling FS (Score:2)
In My experience at my last position....
ext3 just feels like a kludge. It's not very elegant, but does offer a simple upgrade and degrades to ext2 when mount as such.
jfs is still having issues (in the latest freshmeat announcement fifos are now working.
Mostly I'm glad that reiser will be in the kernel. It's in my opinion the most stable and elegant so far.
Re:Vulnerability in ReiserFS (Score:4)
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)
This is just what linux needs (Score:2)
as somebody else said, you really should check out www.namesys.com [namesys.com] as soon as the slashdot effect wears off.
ReiserFS is much more than just a journaling file system with a tree structure. It has also some functionality from databases and full text search in the file name space. It therefore combines the advantages of the search engine (just enter some words), the database (strict mappings from key to value) and the classic tree structure.
It can also handle extremely small files efficiently, so that you do not have to write storage layers for your object oriented applications. If you want to store something that is 50 bytes large, you just create a file to store it, and it will not consume insane amounts of memory in your harddisk.
This means that you can boost the performance of everything that uses small files (some simple databases, mail and news servers, apache etc.) significantly by switching to ReiserFS.
People often complain that the open source software model does not produce many really new technologies: ReiserFS is one of those new technologies. It might even be the "killer application" for linux two years from now.
greetings,
AC
Re:Stable (Score:2)
SuSE patch to kernel 2.2.14). A journalling filesystem is pretty much
indispensable: I've probably had two dozen dirty shutdowns in that
time, a couple during large file operations, and I would have hated to
have been using ext2. The few bugs that have shown up seem pretty
small fry compared to the risks of running fscks every week or so.
I wouldn't use it for a server at the moment, not until there are a
few more dot-releases, but I'm using FreeBSD for my server in any
case.
Hans Reiser - the next Einstein (Score:2)
Entered UC Berkeley after completing the eighth grade, received a BA in Systematizing, which was an individual major.
Whoa! Entered UC Berkeley after 8th grade! I think we have the next Einstein on our hands.Re:Does it work with LILO yet? (Score:2)
Re:Some thoughts. (Score:2)
Re:Reiserfs is great.. and a warning... (Score:2)
Re:Vulnerability in ReiserFS (Score:3)
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..
specifically ... (Score:2)
Other Journalling FS (Score:3)
Very good news (Score:2)
In a nutshell: it rocks
And not having to fsck a 15 Gig partition every umpteenth time saves a lot of time and nerves (have you noticed, that this always happens when when you're in a hurry ?)
Re:More info (Score:2)
Re:Other Journalling FS (Score:2)
>>>>>>>>>>
Yuck. To some extent that's fine, but eventually, you get a bunch of layers that really needn't be there, and a core layer that is rapidly decaying. The whole idea of "layers of software" make me retch. I'm a more horizontal person myself. Anyway, ext2 is nothing special. It's stable, and it's reasonably fast, but the design has been done (better) before in fs's like FFS. (Before anybody says ext2 is faster, mount it sync and see what happens.) ReiserFS has shown that it is quite stable, and very fast. In other words, better than ext2, and better than ext3 ever can be. I think that its here at the right time, and its done well enough to switch to it. At some point, it just makes sense to throw away the old code (but not the old ideas) and implement the thing better. ReiserFS is that better implementation, so stop bitching and do some debugging...
As for data loss, journelling FSs give no protection against that, they just provide fs consistancy. Anything JFS does is its own feature.
SGI's XFS rocks as well (Score:4)
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:More info (Score:2)
Thimo
--
Re:Stable - Root Partition Howto (Score:4)
Re:Large root partitions(was: Re:Very good news) (Score:2)
Of course not.
> From the four partitions, one goes to W2K (gak!), one is swap, one is
> I'm sure there's a way around this, but I have no clue how.
The '4 partition limit' is on primary partitions. You can have as much logical partitions as you want (ie: those are a chained list of partition residing in a primary partition, called an 'extended' partition. In the pure Microsoft way of thinking, you can only have one extended partition). Techincally, you only need three primary partitions in your laptop: one for W2K, one for linux, and one for the extended partition.
Furthermore, linux is able to boot on non primary partitions.
And there are tools out there to hide/show partitions at boot (GRUB can do this for instance. I highly recommand GRUB over LILO), so you can have dozen of primary partitions, but only 4 existing at the same time.
Lastly, it may be possible to use bsd disklabels, which are ways to subdivise an existing partition. You could put linux in BSD slices, but this starts to be slightly more serious hacking (but is doable).
> Thanks for the hint, do you have a good pointer where to educate myself ?
Various man pages/HOWTO should do the trick.
Cheers,
--fred
Re:More info (Score:2)
journals are designed so this isn't an issue. That is you make sure the journal is committed before you write the data, then you erase the journal. There of course needs to be enough journal space so that you can have several going at once (once process writing data when anougher starts writting into it's journal) Harddrives can tell you when something is comitted to disk, so if the journal is corrupt (easy to tell) you ignore it as nothing is wrong with the data it was refering to. If the journal is fine you check the data (sectors) it refers to and do a fsck, but since only those sector can be corrupt those are the only ones you check, not the whole disk.
FreeBSD's softupdates achives the same ends, but with a completely different means.
Yes (Score:2)
As an aside, I have also used SGI's XFS (downloaded from cvs) successfully with lilo. Grub doesn't seem to like 2.4.0 at all with any filesystem type (the hang happens at the start of the kernel unpacking process and may be filesystem independent, but in any event ext2 and reiser fail equally), so I dumped it in favor of lilo for the time being and thus haven't tested it with XFS.
In short, in my experience either journalling filesystem works fine with lilo.
Hopefully so (was: Very good news) (Score:2)
It was an SMP system (my corporate web-proxy), running ReiserFS on 2.2.1X, with 5 x 9 Gb disks
It rocked - until it stopped working at all. There was some race which locked the CPUs after at most one day of uptime. Granted, the box is plenty loaded, at the time was pretty low on RAM, etc etc etc.
Still, I had to revert to ext2 and it's been running perfectly since.
On the good side, I haven't had any problem on UP boxes or not-so-loaded systems (probably they just couldn't gather enough load to trigger the bug
So I really hope that the problems are fixed, and that ReiserFS (possibly along with its "raw" variant, which has great promise for web-caches and news-servers) will be mainstream soon.
Re:Okaaaaay... (Score:3)
Re:Distributions? (Score:2)
SuSE 7.0 includes ReiserFS and ships with the 2.2.16 kernel.
Re:Very good news (Score:3)
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....:)
--
Re:x86 only... (Score:2)
Oh, my main machine is an SMP x86, I've never had any SMP related issues (though there apparantly were some a while back
Ben
Re:More info (Score:2)
Last time I checked, rfs journal only meta-data modification. It is not a real transactional system, only a avoid-fsck thingy. Less interesting, but faster (you have to write before/after images in a transactional system)
Cheers,
--fred
Linux kernel vulnerability exposed by ReiserFS (Score:4)
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 [lwn.net] and this page [lwn.net] 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--
Re:Stable (Score:2)