Follow Slashdot stories on Twitter


Forgot your password?
Linux Software

ResierFS In Latest 2.4.1 Prepatches 181

Fluffy the Cat writes: "ReiserFS has appeared in the latest 2.4.1 prepatches on 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.
This discussion has been archived. No new comments can be posted.

ResierFS In Latest 2.4.1 prepatches

Comments Filter:
  • by Anonymous Coward
    There were people working on another file system called Charon(sp?)... has that project died, as I've not heard any updates. From an initial read in a news group the features sounded promising.
  • I assume this is fixed by now btw, this has been confirmed to happen with 3.5.28 anyway...
  • by benmhall ( 9092 ) on Tuesday January 16, 2001 @04:56AM (#505059) Homepage Journal

    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 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,

  • Sure, but how many years was he in the 8th Grade?
  • I would like to get started with linux and leave my old platform behind, what is the best distribution and how do I attain it? Thanks
  • I had the EXACT same problem, excpept that it had nothing todo with NFS. I just had a lockup one day, rebooted, and 3 files gave me that same problem. I switched everything back to ext2 . . .
  • 15GB? 70GB?
    # /bin/df -kl|awk '{A+=$2}END{print A}'

    All vxfs, of course.
  • Er, nobody ever said you had to back up everything.

    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.

  • Why is that article (the one at []) dated March 30 - 31 2001? Last I checked, thats another 2 and a half months away.
  • In a word, yes. I am running Resierfs on some Squid boxes, each with between 17gb and 200gb of disk spread across a raid 0 striped LVM volume, and Reiserfs has been nothing short of a miracle if one of the boxes goes down for any reason other than a planned reboot. An hour long fsck on a web cache that (unfortunately) doesn't always leave an alternate method of retreiving pages to users on the inside just is NOT acceptable, so Reiserfs has really saved the day for me.

    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.
  • by Anonymous Coward
    If you are going to use Reiserfs, might as well upgrade Lilo to the latest which is 21.6. It is not a requirement, but it makes a couple of small things easier because Lilo 21.6 is Reiserfs aware.

    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.)

  • I think not. I was informing the gentleman that this is in fact the way that Free software development works, and hoping to dispell the confusion caused by his misinterpretation of the article. How much more on topic can you get?
  • I'm sorry for saying it, and I should know better than to feed an obvious troll, but you're an idiot. This is how Linux kernel development works. We have finished creating 2.4.0, it works, it rocks, and now we start working on the next version. Sure, it will include bug fixing on things that we probably managed to miss in 2.4.0 (for instance, fat32 doesn't work on 64bit systems in 2.4.0, as if that matters), but now we can start adding new features. This isn't the same idea as MS and their infinite servicepacks to NT 4, this is actual, honest to goodness progress, and it is good that way.
  • This howto involved creating a seperate partition and copying your data over to it, then switching lilo to boot off of it. As far as I have seen there is no easy way to upgrade directly from ext2 to reiserfs...
  • It's pretty easy to upgrade to ReiserFS assuming you have enough free space. Take a look at man resize2fs. Just use resize2fs to make a new partition and copy everything to the new partition. Then make the old partition into a reiserfs partition and copy everything back (though you have to make sure you mount the ReiserFS partition with the notail option to copy /boot correctly). You also have to make sure it is mounted notail any other time you copy stuff to the /boot. I'm guessing that future versions of LILO will remove this requirement.

    "Homo sum: humani nil a me alienum puto"
    (I am a man: nothing human is alien to me)

  • 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).

    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?

  • Actually leaving /boot as ext2 is a pretty good idea. When /boot is ReiserFS you have to remount the file system with the notail option before you copy stuff to /boot. Your way prevents you from screwing up and forgetting to do this.

    "Homo sum: humani nil a me alienum puto"
    (I am a man: nothing human is alien to me)

  • It is, in fact, pretty much the default on SuSE 7.0. That's why I am using it on this box: my 40Gb partition fscks faster than I can read it. This can't be a bad thing!
  • by mjh ( 57755 ) <> on Tuesday January 16, 2001 @09:29AM (#505076) Homepage Journal
    I like reiser, and I'm glad for my nice quick reboots, but I don't understand how they claim so much better performance. I did a test using bonnie []. I first ran the test on /home using ext2, then unmounted /home, did a mkreiserfs on it, remounted, and redid the test. Here's the results

    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.

  • like when someone kicks out the power cable

    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.

  • I've been using ReiserFS on a few machines. Primarily, it is the filesystem on my 40gb MP3 drives, and when 2.4.0 and the corresponding Reiserfs patch arrived, I actually switched my /usr partition over... it does feel noticeably faster, but I use it with certain caveats. First, these are personal machines, not multi-user, and second, I have backups of my data offsite.

    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.
  • If you dont like the advertising I assume you could just edit the source and remove it. Theres a Swansea University advert in the bootup for 2.2.x kernels. Doesnt bother me, I dont boot up much.
  • All this AFAIK, but I can be proven wrong once again...

    > 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.


  • by autocracy ( 192714 ) <[slashdot2007] [at] []> on Tuesday January 16, 2001 @05:04AM (#505081) Homepage
    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!

  • Yes, Microsoft only took 20 years to provide an OS with a journalling file system - I guess that's innovation in action.
  • They're striving for a filesystem with plugins, so it would be very extendable.

    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 [] 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.

    The problem is, that those Data Blades messed directly with the kernel of the database engine.

    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.

  • Okay, so when will someone make a good reiserfsck?
  • As for the questions...
    If this was to go into a
    STABLE Kernel, shouldn't it have been introduced into the DEVELOPMENT kernels first?

    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:

    • The first conclusion was that "it's not going into 2.3.frozen-for-2.4"
    • The second conclusion was that the serious flaming between Alex Viro and Hans Reiser resulted in the ReiserFS team doing a lot of work on interfacing their code "more appropriately" to the Linux VFS layer which has changed significantly in preparation for 2.4.

    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...

  • Before reiserfs had logging, I believe it was much faster for many many small files, and slghtly faster for common cases. Of course journalling is going to make it slower on the average than a non-journalling file system, however I'm willing to bet that certain extreme types of file types are still faster than ext2 due to the optimized nature of storage on reiserfs. (Go read the white papers for details.)

    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.
  • by Anonymous Coward
    It also depends on whether the file system was mounted "notail" or not. This option does not pack fragments, trading slightly better space utilization for speed. It also matters if the files were created with "tails". Mounting "notail" still requires previously stored files to be unpacked when reading if they have tails. The ReiserFS is highly configurable so you might want to read through the mailing list archives and white papers at the Reiserfs web site so that you will know how to get the most out of your ReiserFS.
  • Thanks for the Link. Actually it appears that XFS fares the best of all the filesystems. I attended a Linux Road Tour from SGI about a year ago. I attended a session on XFS and I was truly blown away by it's capabilities. XFS on IRIX is truly amazing and for SGI to opening up the specs for the Linux community is truly admirable. XFS is SGI's crown jewels and they are giving it to the community. For more on XFS, read this []. Alternatively, you can watch a streaming video about XFS here []. XFS will be the industrial strength filesystem that will push Linux into the High Availability server arena. For desktops, ReiserFS should still be sufficient.
  • 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.

  • At least in part, it's faster because rather than using a linear list of the files in a particular directory/inode, it uses a B+ tree. Which means that finding a particular file isn't an O(n) lookup, it's an O(logn) lookup.

    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).

  • As a little experiment, I tried how long a file name could be on recent ReiserFS versions (ReiserFS 3.6.25 on kernel 2.4.0), and it turned out to be a whopping 4032 characters!

    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

  • by -stax ( 34630 )
    Finally, linux has the holy grail of industrial strength operating systems! This is the one major reason why i use mandrake now, who wants to wait for a fscking fsck?
    /. poster #104543567
  • The fact that "blades" are liable to be "dangerously sharp" is a pretty welcome bit of analogy. If you don't know what you're doing, it's easy to chop up things you didn't plan to chop up. "Oops, I really wanted to keep that hand!"

    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:

    • Something to support more efficient Squid HTTP Cache operations is an almost certain example;
    • Something to support ATIME-less operations (as is helpful, if memory serves, with news servers) would be a likely example;
    • I wouldn't be surprised to see someone implement a "plugin" to support building a simple DBMS system (perhaps analagous to DBM) atop ReiserFS.

    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.

  • Lightweight? You have any 70GB RAID _laptops_ kicking about the place? .. You do? I can have one? It'll be in the post by the weekend? Cool, and thanks!! :)

    p.s. My sig is totally and utterly out of date :)
    Azrael - The Angel of Death
    posted with: Mozilla (0.7)
  • Linus needs to go back to Univ ...

    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.

  • I had the same thing. Which version of the kernel were you using? There was a known problem with smp.c which very seldom reared its ugly head, unless you had a FS which really taxed teh kernel. Ext2fs could very seldom do it. ReiserFS is "advanced" enough that it did it very often. It was fixed in 2.2.16. Not the fault of ReiserFS.

    My recipe for disaster was to have a really big benchmark running.

  • by Outland Traveller ( 12138 ) on Tuesday January 16, 2001 @10:05AM (#505097)
    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 :)
  • by aqua ( 3874 ) on Tuesday January 16, 2001 @10:13AM (#505098)
    fsck: No, you just replay the journal (whatever metadata writes were pending) on mount. Takes a few seconds, then the fs is ready for use. If the tree gets damaged somehow, reiserfsck can help, though it's in its infancy and nowhere near as reliable or robust as e2fsck.

    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.

  • by chrisdb ( 90311 ) on Tuesday January 16, 2001 @04:25AM (#505099) Homepage
    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 ?...
  • A fair chunk of the "namespace" stuff represents wishful thinking moreso than any realistically expected reality.

    The more usual literature on "namespaces" can be found discussed with The Use of Name Spaces in Plan 9. [] 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:

    • It's a "private" mount, visible only to the process that did the mounting and its children;
    • The mount doesn't require root access.

    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.

  • That's "...should bear some interesting fruit..."
  • Can you run ReiserFS on a software RAID-[045] device yet?
  • I'm tired of waiting for reiserfs patches in order to upgrade a kernel. It's about the time.
  • Nice to see ReiserFS is included in the 2.4.1 Kernel. I am using it for 1,5 or so Years now and never had problems, except that one time where a Ram chip barfed. In my eyes ReiserFS is a stable and proven Filesystem, which is a lot more efficient and faster than ext2.
  • The 2.4 kernel has barely been released, and there's already development on a 2.4.1? Pardon me as I go into hysterics!

    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?

  • I've goot zillions of terabytes of harddisk, formatted with journaling-FAT16 my Commodore Plus/4.
  • Keep in mind it really hasn't been ported to anything other than x86. I hear the ports that are being done are targetted for the 2.4.x series.

    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
  • In file systems, one thing, and one thing alone is paramount: data integrity. Performance and efficiency is irrelevant. You need a very esoteric application before this is no longer true.

    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.
  • how to pronounce it? Ricer FS? Raiser FS? Riser FS?
  • I for one would be quite happy if someone competent ported the BSD UFS to Linux. It'd be great to have a unified file system between both platforms.
  • After a BAD crash while experimenting with Utah-GLX last summer, I migrated my main box onto reiserfs (about 20GB worth of filesystems so far). I haven't had a single problem with it yet. I've only run it with the 2.2/2.3 kernels, so I can't really comment on interactions with 2.4.0 yet.

    Here's a testimonial from namesys [] web site that helped to convince me: 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 (also, which is the one and only anonymous CVS checkout point for mozilla. That server has run flawlessly under very heavy load since its birth.

  • 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.

  • 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.

  • I guess we just have different priorities then. On my home machine, I would much rather have performance than data integrity (up to a point of course ;) Of course, I have scripts sync my data directories to my trusty FreeBSD server, so a data loss wouldn't hit me as hard. Of course, I wouldn't run a green filesystem on by BSD server, so I guess I can see where you're coming from. I still think you should invest in a good tape drive and live on the edge a little ;)
  • by Psiren ( 6145 ) on Tuesday January 16, 2001 @05:33AM (#505122)
    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.

  • by geirt ( 55254 ) on Tuesday January 16, 2001 @05:33AM (#505123)

    This was sendt to the kernel list a week ago by Linus: /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.

  • I think your concerns are exaggerated. It's safe, stable, and benchmarks put it at about 15% faster than ext2. I've been using it on various desktops for over a year and it is GREAT.
  • by Spoing ( 152917 ) on Tuesday January 16, 2001 @05:39AM (#505126) Homepage
    No matter how forgiving and PC your attitude is there are most definately dumb questions . Here are a couple more;

    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.

    1. Q. How well does ResierFS handle this (if at all)?
    2. 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.

  • I have been using ReiserFS with SuSE for a while but one thing that always bothered me is that lilo can't boot the kernel off a partition with ReiserFS so I always need at least one ext2 partition just for this purpose. I heard LILO was starting to support Reiser, anyone know for sure?
  • i had tried reiser previously and it ate my disk

    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.
  • I like ReiserFS. It's FAST, it's stable, and it's FAST.

    However, I would like to throw in some points:

    • If this was to go into a STABLE Kernel, shouldn't it have been introduced into the DEVELOPMENT kernels -first-? After all, that's why the series were split the way they were. Too much development code in a production kernel renders it the same as a development kernel.
    • There was a -lot- of fighting, over on the kernel developer's list at one point, over ReiserFS. How did it get settled, and how now?

    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.

  • officially? I'm not sure, but it worked fine for me. I was using two 30GB IDE disks and software RAID0 with the 2.4test (it was test9, I believe) series. on my root partition, no less :) altogether, very fast and stable.

    on the other hand, I haven't read about it anywhere, so I wouldn't try on, say, my mission critical corporate server.
  • by Anonymous Coward on Tuesday January 16, 2001 @06:01AM (#505142)
    For comparision of JFS, XFS, Ext3, and ReiserFs see []
  • From the reiserfs-list:
    Ok, here is reiserfs utils directory for linux-2.4.1-pre7 : iserfs-utils-patch.bz2

    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: 9413577&w=2

  • I heard LILO was starting to support Reiser, anyone know for sure?

    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 [] 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
  • Maybe now ReiserFS will get ported to other architectures, so my little multia MP3 server won't take forever fscking the 20G data partition :-)
  • The most important thing is to have /home in a separate partition. That way you can experiment with all kind of distributions, always reformat /, but retain all your stuff. swap should be separate too, of course. And remember, Linux lives quite happily in extended partitions. You can have only four primary but you can have up to seven separate partitions (if I'm not mistaken) in every one of them if you turn it to extended. By doing this you don't lose performance or stability.

    With the new lilo (or if you prefer the grub) you can boot from any cylinder so you don't need separate /boot anymore.

    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.
  • 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.

  • by Azog ( 20907 ) on Tuesday January 16, 2001 @06:58AM (#505148) Homepage
    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)
  • by Anonymous Coward

    as somebody else said, you really should check out [] 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.


  • I've been using reiserfs on my laptop for about 6 months (with the
    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

  • 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.
  • Yup. The newest LILO (26.1?) supports booting from ReiserFS partition. Check
  • Although it wasn't on the official Linux kernel 2.3/2.4.xtest - it was used quite extensivley by people, and the main download site of sourceforge - got all the partitions with ReiserFs - so when you do CVS check in/out, or downloading from sourceforge - you're downloading from a ReiserFS built machine - with quite big hard disks - 750GB

  • You are also better off using the 3.5.x utils as reiserfs 3.6.x does not have a functional fsck yet(its in the works though). Not that you'll need it too often, but just in case.

  • by AndroSyn ( 89960 ) on Tuesday January 16, 2001 @07:19AM (#505171) Homepage
    This bug has been fixed.

    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 `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxx': File name too long

    The said filesystem is reiserfs..

  • Specifically, read the partition howto [], the man pages for fdisk, and the lilo/grub man/info pages. A good documentation reference point for Linux in general (including links to all the HOWTOs, etc. is the Linux Documentaiton Project [].
  • by Helmholtz ( 2715 ) on Tuesday January 16, 2001 @04:32AM (#505180) Homepage
    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.
  • After talking with various folks more knowledgeable then me (stability issues) I decided to use ReiserFS for the 15 Gig root partition on my laptop.

    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 ?)

  • In addition to the stuff the other guy mentioned, journeling filesystems also seem to be able to handle changes like unlinking files much more quickly than ext or FFS. After doing a full build, deleting the XFree86 source tree takes several minutes on ext2, but is more or less instantaneous on ReiserFS.
  • implementation I like; a thin layer ontop of proven code
    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.
  • by FreeUser ( 11483 ) on Tuesday January 16, 2001 @06:34AM (#505197)
    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.
  • Link is wrong, it should be [] which redirects you to [].

  • by leistnerm ( 73722 ) on Tuesday January 16, 2001 @06:45AM (#505200)
    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. ml
  • > I'm probably gonna embarrass myselfe here

    Of course not.

    > From the four partitions, one goes to W2K (gak!), one is swap, one is /boot and the remaining one is /root.

    > 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.


  • 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.

  • by FreeUser ( 11483 )
    I have used reiserfs successfully with both grub and lilo, running Mandrake 7.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.
  • I hate to be the voice that doesn't sing along the choir lines, but I have to report problems with ReiserFS.

    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.
  • by abelsson ( 21706 ) on Tuesday January 16, 2001 @04:39AM (#505214) Homepage []
  • This is only, because SuSE is not as widespread in the rest of the world, as compared to Europe.

    SuSE 7.0 includes ReiserFS and ships with the 2.2.16 kernel.

  • by larien ( 5608 ) on Tuesday January 16, 2001 @04:42AM (#505217) Homepage Journal
    15GB? Lightweight! :) We have a 70GB RAID partition on our Solaris server. Having a journaled file system on that (Solaris 7 has UFS logging) makes life so much better on hard reboots (like when someone kicks out the power cable; grr....). The previous server could take 20 minutes to fsck about half that disk space; now it just boots up without any trouble.

    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....:)

  • Hmm.. not so! There is a working Alpha port (and likely others in the works..)

    Oh, my main machine is an SMP x86, I've never had any SMP related issues (though there apparantly were some a while back

  • > You don't lose your file, the point of the Journal is quick and easy recovery. If you lost your file, you're no longer recovering it.

    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)


  • by Mr Z ( 6791 ) on Tuesday January 16, 2001 @08:42AM (#505229) Homepage Journal

    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.

  • If you're unlucky, anybody who can create a file on your reiser FS can get a bufferoverflow into kernelspace. (Ie: Free root for all). Not nice. YMMV.

In English, every word can be verbed. Would that it were so in our programming languages.