begin Jeff Bonner quotation: > First, the usual caveat: ReiserFS is an "experimental" kernel feature > and as such, you should observe all the normal cautions if this is a > critical production environment. Also, there is no dump and restore > with Reiser, but then again neither does the 2.4 kernel have it in the > first place. > > That having been said, I think most people would agree that ReiserFS is > mature enough for almost any use at this point, and I'm not aware of any > glaring problems with it. Aside from, say, the lack of good repair tools. Or do they have one now? That really works? I wouldn't consider ReiserFS suitable for any mission-critical systems. > From what I understand, you can run ReiserFS on any partition, except > swap. On the other hand, 32MB is reserved for the journal, so it would > be rather wasteful to use it on very small partitions like /boot. Is that 32MB a fixed value regardless of the size of the fs? Ext3's journal varies in size according to the size of the fs. The ext3 journal in my /boot partition is only 1MB. > ReiserFS is supposed to be moving towards an extended filesystem that > can be used as a high-performance DB, with advanced query and > transaction support. This may be of particular benefit in your case, > down the road at least. For now, the "balanced tree" should give you > performance increases, as much as 15 times that of ext2 (in some cases). Possibly. Of course, when people run these tests for promotional or journalistic purposes, they're generally doing it on freshly-made partitions. Try it on a ReiserFS partition that's been heavily used for a year and see if you still get such nice results. > You may want to examine 'ext3' as well. It's backwards-compatible with > ext2; in fact you can simply convert your existing ext2 partitions by > "adding" the journal. This is done with the tune2fs utility, and by > changing your /etc/fstab. Then you would run the mkinitrd so your > system starts using it upon the next boot. Its performance won't be > that of a "pure" journaling system, but the ease of conversion may > mitigate that for some people. Of course, I should add that ext3 is > also "experimental". But quite stable at this point. I've been running ext3 on all my fs's for several months, and have never seen a problem that resulted from ext3 itself. > Last but not least, you should understand (if you don't already) the > difference between logging and journaling, namely that the former keeps > track of both data and inodes, while the latter handles only inodes. > Journaling requires less system resources, but logging would recover any > lost data much faster. Reiser, XFS and ext3 all have options to support > both these methods. From my understanding, you're confusing a couple of different things here. The distinction you're trying to make is between "full data journaling", which writes file data as well as directory and inode information to the journal, and "metadata-only journaling", which only writes directory and inode changes to the journal. If you journal only the metadata (which is the default mode for all the available Linux journaling fs's, I believe), then it is possible that some file data may be lost if the system goes down without being able to clean things up nicely (as in a catastrophic system crash, a hardware failure, or loss of power). So to say that full data journaling will recover data "faster" is not really right -- metadata-only journaling may actually _not_ be able to recover all your data. What metadata-only journaling _can_ guarantee is that the filesystem will be in a consistent state when the system comes back up and the journal has been replayed, because inode and directory changes have been journaled. A "logging" filesystem, as I understand the term, is actually something else entirely. Craig
Attachment:
pgpeqSIGGbB6T.pgp
Description: PGP signature