Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Linux Software

Reiser4 Benchmarks 414

unmadindu writes "Hans Reiser has benchmarked Reiser4 against ext3 and Reiserfs 3. Reiser4 turns out to be way faster than V3, and for ext3, why don't you check out the results yourself ? Hans Reiser states, "these benchmarks mean to me that our performance is now good enough to ship V4 to users", and he will be probably sending in a patch within the next couple of weeks to be included in the 2.6/2.5 kernel."
This discussion has been archived. No new comments can be posted.

Reiser4 Benchmarks

Comments Filter:
  • Reliability (Score:5, Interesting)

    by prestwich ( 123353 ) on Saturday July 26, 2003 @01:27PM (#6540251) Homepage
    My one concern is reliability and recovery from failure; I've had a few cases where my belief in ReiserFS has been questioned; however I can't get Ext3 to build on larger than 500GB arrays.

    At this point I'd happily choose based on reliability/recoverability/stability not raw speed.
    • Re:Reliability (Score:5, Insightful)

      by globalar ( 669767 ) on Saturday July 26, 2003 @01:44PM (#6540343) Homepage
      Exactly. RAM, CPU, and storage space are ever increasing. Now we need better ways to organize data, access it, protect it, and back it up.

      The fact of the matter is, it is easier to make a fast system than a stable, reliable one.
      • Re:Reliability (Score:5, Informative)

        by hankaholic ( 32239 ) on Saturday July 26, 2003 @04:02PM (#6541052)
        You obviously know nothing about ReiserFS.

        ReiserFS does have speed as a goal; however, with ReiserFS 4, all filesystem operations are now atomic, which is functionally equivalent to having full data (not just metadata) journalling.

        In addition, having the fastest CPU in the world won't make ext[23] better at things for which ReiserFS is fast.

        CPU speeds are increasing. Storage space is increasing. RAM is cheap.

        However, none of that equates to "disks are fast". Having a fast CPU with a slow filesystem is like having a gigabit LAN connected to the Internet via dialup. Sure, internally you're quite good, but throughput will still suck eggs.

        The fact of the matter is, it is easier to have no clue what you're talking about than to read a little bit before posting.
        • Features (Score:3, Interesting)

          by einhverfr ( 238914 )
          ReiserFS is really good at some things (and I actually recommend it for some things) but for my main system filesystems, I find that Reiserfs lacks some of the things that EXT2/3 has that are very useful--

          File attributes including things like "Append Only" although these can also be ways of screwing up your system (who'da thunk Qmail doesn't like append-only log files?).... See man chattr for more info....

          So I am happy to use it for directories where I don't have special needs for the filesystem, but for
          • Re:Features (Score:4, Informative)

            by hankaholic ( 32239 ) on Sunday July 27, 2003 @10:59AM (#6544278)
            I'm interested.

            Are there features other than attributes provided by ext[23] which ReiserFS can't provide?

            Regarding the attributes, ReiserFS can't do the following "useful" things:

            - Excluding a single file from access-time logging.

            - Append-only would be useful in certain cases.

            - 'c' (compress file contents) -- Ext[23] doesn't do this yet, and ReiserFS doesn't either, but they both will support it later.

            - 'D' (dirsync) attribute -- Other than ensuring that filesystem metadata operations are completed successfully before proceeding, I can't imagine a beneficial use of this attribute. ReiserFS already journals all metadata, and V4 journals everything (and does it faster).

            - 'd' (do not back up using dump) -- AFAIK you can't use dump to back up a ReiserFS partition anyways, but tar still exists, and I'm sure there are wrapper scripts for the die-hard dump users.

            - 'E' (error in compression) doesn't seem to apply to general (current) use of ext[23], and doesn't have an analogue in ReiserFS.

            - 'I' (hash-indexed directory) -- ReiserFS' directory algorithms are much (much!) faster than ext[23]. ReiserFS will eventually support directory plugins, which allow one to set a per-directory hashing scheme. I note that ext[23] doesn't allow modification of this attribute, so I'm not sure if/how it allows you to choose a hashing scheme.

            - Immutable ('i') bit -- This might be useful in some circumstances, such as a setuid binary. Not supported by ReiserFS.

            - The 'j' option is meant to get around the fact that ext[23] only journals metadata unless mounted with "data=journal". As mentioned elsewhere, ReiserFS' long-term goal is to provide fully atomic file operations, which provides the benefits of data journalling with none of the burdens. Thus, ReiserFS V3 doesn't support this attribute, as the time spent in adding this feature would have been better spent working on V4. Note that with V4 all operations are atomic, which has the effect of turning this flag on for every file.

            - 's' (zero file contents upon delete) -- ReiserFS doesn't support this.

            - 'S' (write file synchronously) is likely used in cases where preserving file integrity is important. ReiserFS' journalling (especially in V4) provides this "for free".

            - 'T' (top of directory heirarchy) is used to get around an ext[23] weakness. I don't recall details, but I believe it's something related to preventing fragmentation and grouping similar files together for enhanced performance. ReiserFS (especially V4) is already quite fast, and with code-level optimizations will likely get faster.

            - 't' (don't merge tails) does not apply to current ext3 code, as tails aren't yet merged anyways. This will be used as a flag to write the file to disk in such a way as to be compatible with LILO and other boot loaders. At present I'm not aware of any special issues with ReiserFS' tail packing (which does exist, by the way) with respect to LILO. Note that a ReiserFS partition can be mounted with the "notail" option if you want, which is feature-wise equal to ext[23], which don't seem to provide tail packing at all right now (and if they do, someone needs to update the chattr man page).

            - 'u' (back up upon deletion) -- ReiserFS doesn't support this.

            - 'X' and 'Z' relate to compression, and do not apply to ext[23] or ReiserFS at the moment. ReiserFS will eventually support compression plugins, as well as encryption plugins.

            So of the attributes, the only ones which might actually be of some use in the context of ReiserFS would be exclusion from atime logging, append-only, the immutable bit, zero-contents-upon-delete (although future crypto plugins will destroy the need for this feature), and back up upon deletion.

            Anything I've missed?
    • Re:Reliability (Score:5, Informative)

      by SaDan ( 81097 ) on Saturday July 26, 2003 @01:48PM (#6540368) Homepage
      ReiserFS has worked pretty good on 1.2TB RAID-5 array I helped build. We're running RedHat 7.2 on a box with a Promise SX6000 RAID controller.

      The drivers are crap, and the box dies about every week or so. Haven't lost a single file yet, and we're at 91% filesystem useage (millions of files).

      The / filesystem is ext3. It's about 20gigs, and has had to have files restored several times.

      I have a lot of confidence in ReiserFS, after seeing the incredible amount of abuse on this one particular machine. I have run ReiserFS for quite a while now (ever since it was part of the kernel) for all of my home systems, and have never had a single issue with those filesystems.

      Looking forward to what ReiserFS4 will bring.
      • Re:Reliability (Score:5, Interesting)

        by Billings ( 87611 ) on Saturday July 26, 2003 @04:02PM (#6541048)
        Yeah, you won't lose files, but you'll lose data. It's been noted elsewhere in this article's comments in more technical jargon, but it is a known flaw in ReiserFS that blocks of data can be written to flat out wrong areas. As an example, I had an outage while I was working with my config files and running an apt-get update;apt-get dist-upgrade. Reiser then managed to write the middle of a debian package file to whatever config file I was working with.

        Had me confused to hell until I saw a newsgroup discussion that mentioned the exact problem I was having. Does Hans Reiser know about this problem? Oh, yeah. He does. Is he concerned about it? No, he's not. In his own words he's not. And ReiserFS fails silently; you'll never know until you find it.

        When I setup ReiserFS on my machine, I was aware of similar complaints, but I dismissed them as fear of trying something unproven. And I was happy with ReiserFS for quite awhile, because I never saw anything wrong (unlike ext2/3). But I really can't support a FS that has these kinds of data integrity issues if the team has that kind of attitude towards them.
        • Re:Reliability (Score:5, Informative)

          by hansreiser ( 6963 ) on Sunday July 27, 2003 @03:23AM (#6543410) Homepage
          If you are using metadata journaling, then a file that you are in the middle of writing to when it crashes can have garbage added to it. Note that Unix filesystems have had this feature since the days of FFS and UFS. Use data-journaling if you find that unacceptable. ReiserFS V3 supports both data-journaling and meta-data journaling now.

          Be warned though, that all fixed location journals double the transfer time cost of performing writes because the data must first be written to the journal, and then written somewhere else. This is why we don't make data journaling the default in v3. Trust me, full data journaling would have been far easier to code first than meta data journaling, but it isn't in the interest of the 'average' user.

          Now V4 is an atomic filesystem, which is much better than data journaling, because it means that all filesystem operations are performed fully atomically. Your write syscall either fully happens or it does not. Applications can have multiple filesystem operations performed atomically. We do this without writing the data twice through use of a technique called wandering logs, which I describe in a posting below (and on our website).
      • The drivers are crap, and the box dies about every week or so

        You should call the server "Kenny"!

        As in Southpark: Oh my God you killed Kenny!

    • Re:Reliability (Score:5, Interesting)

      by cvd6262 ( 180823 ) on Saturday July 26, 2003 @02:03PM (#6540434)
      We had a massive failure of our primary database server while I was out of the country. (Trust me, nothing puts a damper on your day more than having one of your techs call you at midnight from 7,000 miles away.) I blame Reiser. Not because it caused the outage (it was hardware), but because it was so good, it made us a bit lax.

      We're just a small grant lab at a university, so it's not like this was a corporate system or anything, and there had been hardware problems before. Given that most of the people are not techies, they did not know how to ssh in and shutdown -r now, so they would just hit the reset button whenever they thought something was wrong and I wasn't around.

      Anyway, because of Reiser's journalling, the system would come right back up after a forced reboot. I think that the guys in the lab cut the power a couple of times to many and the hard drive just gave out.

      By the way, I just had a tech install a new drive, and Debian base with ssh. I knew the password he would use for root, and I was able to rebuild the entire system and restored 250,000 records in half a day.... From North Africa.

      Try that with a non-*nix.
      • by FyRE666 ( 263011 ) on Saturday July 26, 2003 @02:22PM (#6540506) Homepage
        Given that most of the people are not techies, they did not know how to ssh in and shutdown -r now, so they would just hit the reset button whenever they thought something was wrong and I wasn't around.

        I've found users doing that to my servers before now. I find that hitting them on the nose with a rolled up newspaper and shouting "No! Bad monkey!" in a stern voice tends to stop this behaviour...
        • by Zerbey ( 15536 ) * on Saturday July 26, 2003 @02:46PM (#6540648) Homepage Journal
          I find putting my servers in a locked room where the users cannot get at them even more effective. Just an observation :-)
        • > > they would just hit the reset button
          > I've found users doing that to my servers before now. I find
          > that hitting them on the nose with a rolled up newspaper and
          > shouting "No! Bad monkey!" in a stern voice tends to stop this
          > behaviour...

          Even better: configure the services that the users use so that
          they don't start up at system start. Write a short script that
          starts them all, and whenever you restart the server ssh in and
          run it. That way, if users cold-reset the server, nothing
          • That's a good way to increase job security too, if they don't suspect anything.

            As for the "on only" power switches, most of the computers have bios settings for that, and if not, holding them down for about 4 seconds usually works.
          • Actually, at couldn't you just disconnect the reset switch and hook the power button such that it runs proper shutdown..

            Windows 2000 and XP do this. No reason why Linux couldn't.

          • So, just fix it so that doing Bad Things (like power-cycling) doesn't achieve perceived positive results.
            None of this namby-pamby "fail to reward unpositive behavior" stuff. You are the sysadmin, and it is better to be feared than loved.

            User: Um, I rebooted the box. Er, was that, like, okay?
            You: Und so... Ve haff earned ourzelfs ein timeout in "The Box", hein?
            User: Aiiieieieieeeie!
            You: Mua-ha-ha!
            [Fade to black]
        • Most admins I know would rip off all the user's limbs, execute their family, and say a firm "No". Your way is a little more user friendly.
        • by jd ( 1658 ) <imipak AT yahoo DOT com> on Saturday July 26, 2003 @04:06PM (#6541074) Homepage Journal
          Given that techs are supposed to... well, use high-tech, I sugest using a high-tech version of the newspaper. Now, what high-tech device can you read the news on? Hmmmm. How about this 21" monitor?
      • by RoLi ( 141856 )
        From North Africa.

        Try that with a non-*nix.

        Aw, that's a non-issue. MCSEs are so cheap that it's no problem to always keep at least one MCSE within a 200 meter radius (300 meters if the MCSE is not overweight and under 30) from the system for 99.9% uptime.

    • Re:Reliability (Score:3, Interesting)

      by shokk ( 187512 )
      When you're talking about that much data, backups become something you're only going to pull out for catastrophic recovery. Something like snapshots become more and more important. Are any of the upcoming Linux filesystems going to address this? I imagine that something like that would begin to take customers away from EMC and Network Appliance, and would put high reliability in the hands of smaller organizations.
  • With all of the focus on the latest hardware and graphics, it's good to know that improvements are being made across the board like this. It gives me faith that Moore's law is a long way from failing!
  • Conversion? (Score:5, Interesting)

    by avalys ( 221114 ) on Saturday July 26, 2003 @01:27PM (#6540255)
    Does anyone know if there will be a conversion utility available - i.e, to convert ReiserFS v3 partitions to v4?
    • Re:Conversion? (Score:3, Informative)

      by mlg9000 ( 515199 )
      ReiserFS v4 is backward compatible with v3. So if there isn't a conversion tool yet (don't know) you'll still be able use your v3 filesystems along side any new v4 filesystems you might add.
      • Re:Conversion? (Score:2, Informative)

        by Anonymous Coward
        No, Reiser4 (not reiserfs4) is not backwards compatible with ReiserFS 3. The filesystem structure has been built from ground up, and one of the reasons why I partitioned my new hard drive to only half its full capacity, for the cp -aR command.
      • Re:Conversion? (Score:5, Informative)

        by hansreiser ( 6963 ) on Saturday July 26, 2003 @02:50PM (#6540673) Homepage
        No, V4 is not backward compatible with V3. V3 and V4 are kept as separate codebases so that the new V4 features don't destabilize V3. We are very serious about avoiding adding new features to V3, so that it can become a zero defect product.

        However, there is a tool called convertfs (as well as tar) which can convert V3 to V4. It can also convert ext2 to V3 or V4 or V3 or V4 to ext2. It is pretty clever (and written by someone outside our team), in that it creates a loop back mounted target filesystem inside a file inside the source filesystem, copies everything from the source to the target, and then reshuffles the blocks of the file so that they are at the offsets on the device that they were at within the file.
        • by Anonymous Coward on Saturday July 26, 2003 @04:28PM (#6541180)
          C'mon folks, can't we find someone more authoritative than this guy. I mean, what would someone whose nick is "hansreiser" know about this stuff.
        • Re:Conversion? (Score:4, Interesting)

          by Jah-Wren Ryel ( 80510 ) on Saturday July 26, 2003 @06:22PM (#6541695)
          Hans - How is scalability? SGI seems to think that ReiserFS doesn't scale at all with multiple CPUs, unlike ext2. At least according to the paper they presented at the Ottawa linux symposium last month:

          (see page 9 of this PDF for the graph) [linuxsymposium.org]

          The implication is a lack of fine-grain locking. Does this new all-atomic, all-the-time implementation automagically bring better locking too?
        • by Billly Gates ( 198444 ) on Saturday July 26, 2003 @10:07PM (#6542565) Journal
          Hans. Thanks for all your cool fs work. I have a request. Would you be interested in porting Reiser to other os's and maybe creating a bsd licensed version for them?

          I like the UFS2 FS for FreeBSD. Its stable but a little sluggish. I think it would be cool to have internal competition but the MS GPL == viral crap has made a dent into the BSD developers. They fear linking to anything gpl would make their kernel gpl as well.

          Anyway this is just a pretty please with a cherry on top. Especially since you are being paid for by grants from DARPA who use Solaris, Linux, FreeBSD, and every Unix os under the sun.

  • by HanzoSan ( 251665 ) *
    how can I install this into Redhat9?
    • Re:ok (Score:4, Interesting)

      by ElGuapoGolf ( 600734 ) on Saturday July 26, 2003 @01:38PM (#6540308) Homepage
      You'll probably have to compile it in yourself for now.

      RH probably will include it in the future, but probably won't give you the option to install on it without jumping thru major hoops.

      RH seems to suffer from a big case of "not-invented-here-itis", and RH users sometimes suffer for it. Not having ReiserFS is one way in which they do.
      • Re:ok (Score:5, Informative)

        by silvaran ( 214334 ) on Saturday July 26, 2003 @01:48PM (#6540367)
        I'm not sure about the exact reasons why they don't support various other filesystems. The default bootup sequence of a RH system uses an initial ramdisk, and actually scans each partition available to find out where they should be mounted (they created nash, NAno SHell, which is just simple support for shell commands as well as fs label scanning). That's why you see the LABEL=/ in your /etc/fstab on a RH system. ResiserFS didn't support filesystem labels until 3.6, so using this setup could mess things up (with 3.5 or older), and justifies your point about having to "jump through hoops" to get reiserfs working. The simplest way I found to move to reiserfs was to change all the LABEL=??? specifications to actual device files, boot from a recovery disk, move everything around while reformatting the partitions as another filesystem, then finally rebooting.
        • Re:ok (Score:3, Informative)

          by Anonymous Coward
          that may be true for existing systems, but in the case of running an install from cd, instead of taking the default, add either "reiserfs" or "reiser" (don't remember which - think the "fs" one) to the boot options at the prompt when booting from the cd. it then adds reiserfs to the list of filesysems you can choose to format new filesystems with in the partitioning tool. pre-existing reiser filesystems will be handled correctly if you don't format them.

          rh supports reiser just fine - they simply hide the o
        • Re:ok (Score:3, Funny)

          by Isldeur ( 125133 )
          The simplest way I found to move to reiserfs was to change all the LABEL=??? specifications to actual device files, boot from a recovery disk, move everything around while reformatting the partitions as another filesystem, then finally rebooting.

          Really? The simplest way I found to move to reiserfs was to use Suse.
  • wait! (Score:5, Insightful)

    by BigBadDude ( 683684 ) on Saturday July 26, 2003 @01:30PM (#6540269)

    hey, I can live with an unstable gnome or Kicq, but a beta filesystem?? no thanks dude!
    • you could if you have spare machine:)

      As it goes for me I can do that with no pain. Seeing what r4 provides migrating my things to r4 would be good. But first place for beta fs is spare machine that is just used to crash test this filesystem.
    • Re:wait! (Score:3, Informative)

      Yep. Testing a beta filesystem is something you do on a spare machine that you are not using at the moment. It would be really cool to help test ReiserFS out, but I only have one machine and can't risk losing all of my work!

  • by GreyWolf3000 ( 468618 ) on Saturday July 26, 2003 @01:30PM (#6540270) Journal
    After reiser4, what filesystems are actually decent competition for it? It'd be nice for OSS to claim not only the best web server (apache), best kernel, and best filesystem.
    • by 1s44c ( 552956 ) on Saturday July 26, 2003 @01:42PM (#6540333)
      After reiser4, what filesystems are actually decent competition for it? It'd be nice for OSS to claim not only the best web server (apache), best kernel, and best filesystem.

      Sick of gentoo zealots throwing plugs in completely unrelated topics? Me too!

      Not to mention the best software installation system ( portage ).
    • Reiser's competition is, in order: SGI XFS and IBM JFS. Oh, and I guess VxFS.
    • by Znork ( 31774 )
      Most of them?

      Dont get me wrong, reiserfs has impressive performance, but the recurring problems with bugs causing crashes when using reiserfs makes me extremely reluctant to use it on any production system.

      A filesystem can have incredible performance, great features and impressive data consistency, but if it crashes the machine it's unusable.

      Currently I dont see the developers of reiserfs paying nearly enough attention to stability, nor do they seem particularly interested in the subject, preferring feat
    • by jd ( 1658 ) <imipak AT yahoo DOT com> on Saturday July 26, 2003 @04:19PM (#6541134) Homepage Journal
      Actually, OSS claims several of the best filing systems! :)

      XFS is probably one of the fastest journalling filesystems out there, all-round, and probably offers the best competition to Reiser4. I'm actually surprised not to see some benchmarks against it, as XFS has gathered quite a following in places.

      The port of the Plan9 filing system is said to be one of the fastest filing systems out there - enough so that it's a part of a Government research program called "Pink", run by some mad scientists at Los Alamos. Yes, that Los Alamos. Again, this would be an excellent FS to have some benchmarks against.

      Last, but not least, Reiser4 didn't do spectacularly well against Ext3 in the benchmarks. I saw plenty of results both ways. Reading vs. Deleting, for example, shows a definite penalty whichever FS you choose, depending on the operations you're performing.

      In the end, if you truly want the fastest system, you should format partitions according to the type of workload they'll be doing. You want fast deletes on a /tmp partition, for example, but you will likely care much more about reading times on your application binaries, and modification times on your data files.

      (Unless you're using the suspend patch a lot, you probably won't want journalling on the /tmp partition, either.)

      A truly optimized system, therefore, isn't about picking your "one true love" of the filesystems. It's about deciding what criteria apply, and then looking to see what filesystem best meets that criteria.

      A mixed-fs machine should be capable of out-performing ANY homogenous-fs machine, no matter what fs the homogenous-fs machine has picked, because a homogenous system will always be a compromise. A mixed-fs system need compromise nothing. (Other than your sanity. Which, being a geek, is just a hinderence anyway.)

      • The port of the Plan9 filing system is said to be one of the fastest filing systems out there - enough so that it's a part of a Government research program called "Pink", run by some mad scientists at Los Alamos.

        I think they are using the Plan 9 network filesystem protocol (9P2000), not the Plan 9 local filesystem (which isn't anything special AFAIK).
  • by jstockdale ( 258118 ) * on Saturday July 26, 2003 @01:31PM (#6540275) Homepage Journal
    I am curious as to whether there are any projects to port Reiser4 to *BSD, particularly FreeBSD 5.x. Does anyone have any thoughts on how difficult a port might be? Can somone more versed in filesystems on *nix enlighten me as to the implimentation differences?
  • by Anonymous Coward
    ...is mostly funny, but is too much of a company filesystem to trust completely.
  • by vadim_t ( 324782 ) on Saturday July 26, 2003 @01:33PM (#6540289) Homepage
    In case anybody cares, "strelka" means "arrow", and "belca" means "squirrel"

    Wonder what naming system they're using. I use names from Alice in Wonderland.
  • by Man In Black ( 11263 ) <{ac.wahs} {ta} {or-ez}> on Saturday July 26, 2003 @01:35PM (#6540293) Homepage
    All these numbers are nice, but I can't make heads or tails of them. Since these are times, I assume lower numbers are better? If so, they why are they usually in red in the report?

    Would this increase the speed of a normal system by any noticable amount? Is it worth my time to switch over my EXT3 filesystem to reiser4? Are there programs that can perform the filesystem change for me?
  • by 0x0d0a ( 568518 ) on Saturday July 26, 2003 @01:36PM (#6540298) Journal
    The statistics on that page are measured in seconds, no? So larger numbers are worse.

    The comparisons are done with [foreign filesystem] divided by reiser4.

    One would think that numbers greater than one, where the foreign filesystem has a long running time and reiser4 a short one, would be the ones that benefit reiser4.

    Yet the numbers *less* than one are green, where Hans says reiser4 is considered better.

    What's going on?

    (Incidently, after having a friend lose a filesystem to buggy reiser code, I'm a bit inclined to wait until people have *seriously* hammered on this).
    • by silvaran ( 214334 ) on Saturday July 26, 2003 @01:56PM (#6540401)
      A. reiser4
      B. ext3 data journalling
      C. ext3

      That's how the filesystems are lettered. In the column headers, you see this:

      A B/A C/A

      So it looks like the first column is the actual time for reiser4 (A), the second column is the ratio between ext3-j (B) and reiser4 (A) which is B divided by A, and the third is ext3 divided by reiser4. So if the number is > 1 (red), it means reiser4 took less time and might be "better". If the number is 0 (green) it means reiser took MORE time.

      I think.
    • by hansreiser ( 6963 ) on Saturday July 26, 2003 @02:59PM (#6540731) Homepage
      The script that creates the comparison tables divides the other filesystems by the base filesystem. The problem is that Reiser4 was used as the base filesystem in one of the benchmarks, but not the other. So in one benchmark, green is good, and the other benchmark, red is good.

      I would have fixed this before posting to lkml, but I had to catch a plane, sorry about that.
  • Bugs (Score:4, Insightful)

    by Kaladis Nefarian ( 655671 ) on Saturday July 26, 2003 @01:37PM (#6540306) Homepage
    While great, this announcement/benchmark/statement does not mean that ReiserFS V4 is ready for production use, just that it is fast. It needs a lot more bug testing before then, so don't rush out and mass-convert to V4 just yet! See here [google.com] for the full thread, rather than just the first post...
  • by Openadvocate ( 573093 ) on Saturday July 26, 2003 @01:41PM (#6540329)
    I realise that it is a bit early to adopt V4, but stable issues aside, which filesystem would YOU choose to for database volumes for fx. Oracle or MySQL?
    • I'd go with XFS. I've never heard of corruption from regular use, while I've heard far too many horror stories about ReiserFS. Aside from the ineptitude at reliability, Reiser's one of the most unpleasant characters I've ever run into in Free/Open software. Stallman at least has reason for what he does. Reiser sends off flames to dev mailing lists (sometimes legally) threatening people for removing the kernel message and command line commercials from his code. Usually, he fires off fiction about "the n
  • XFS? (Score:5, Interesting)

    by leoboiko ( 462141 ) <leoboiko AT gmail DOT com> on Saturday July 26, 2003 @01:45PM (#6540352) Homepage
    How does it compare against everyone's favorite, XFS?
    • ..but however remember that both have different strong points:

      XFS is especially good in dealing with large(and when I say large I mean *LARGE*) files, and IIRC, the all idea behind the Reiser filesystem is to deal with small data objects.

      Anyway, it'd be interesting to see such a benchmark as XFS has the reputation of one of the best(the best???) fs to be used with high hard-disk I/O-s and even higher system loads.....
    • Re:XFS? (Score:3, Insightful)

      by lvdrproject ( 626577 )
      Yeah, really. Currently i'm a big XFS fan, but i've heard a lot of great things about Reiser. That said, i'm not going to switch over to Reiser until i see some good information that suggests that it's worth it. What the advantages are, what the disadvantages are, what happens if you do this or that, numbers about speed or whatever, et cetera, et cetera. I've seen a few good comparisons, but they're either all numbers, or all conjecture. :/

      I'd also like to see it compared to JFS and maybe ext2 (if not ju

  • but will it make it (Score:5, Interesting)

    by DemiKnute ( 237008 ) on Saturday July 26, 2003 @01:46PM (#6540358) Homepage
    So he's submitting it to 2.6, but what are the chances it'll get submitted? Isn't this what caused all of Reiser's bitching a couple of years ago? He waited to long to get RFS into the kernel and ran into the feature freeze, and then pitched a hissy fit.
    • Me too™ (Score:4, Funny)

      by DarkVein ( 5418 ) on Saturday July 26, 2003 @03:15PM (#6540816) Journal
      ...he will be probably sending in a patch within the next couple of weeks to be included in the 2.6/2.5 kernel.

      The first thing that popped into my head when I read that was "uh... feature freeze two weeks ago." I'm sure Reiser's going to have another of his babyish hissy fits. I see another slashdot story in the near future.

      <Reiser> Oh, what about my sponsors! Why are you all playa hat'n on me?

      <EveryoneNotOnTheReiserCheerleadingSquad> You don't get special treatment. You waited too long, and we're not putting your untested code into a frozen code base.

      <Reiser> You're oppressing me! The GPLv3 will fix you all!

      <SomeoneFromFSF> Please shut up, Reiser. You still don't know what the fuck you're talking about.

      <Reiser> Wahh!! My sponsors!

      <Everyone> SHUT UP REISER.

  • by niko9 ( 315647 ) on Saturday July 26, 2003 @01:49PM (#6540370)
    Anybody know what, if any, features are being added for the laptop user? Last time a checked, journaled filesystems, like ext3, were generally a no-no if you wanted you battery to last.

    Maybe a filesystem just for laptop/tablet pc users?
    • by hankaholic ( 32239 ) on Saturday July 26, 2003 @04:17PM (#6541123)
      Operations are journalled in such a way that instead of updating the directory entries (or the file allocation table, or whatever applies to that specific FS) and then writing the new file contents, ReiserFS writes the new contents, and _then_ updates the directory information.

      From the impression I have after having read the V4 design docs, in most cases it's a matter of just writing the new data without touching the old, then updating the bookkeeping entries and marking the old information as unneeded. In theory, this method gives journalling and crash safety "for free".

      In practice, there's the matter of increased code complexity, which means that you'll take a hit on CPU usage, at least until the developers can stop their mad rush to get V4 into Linux 2.6 and work on code-level optimization (as opposed to optimizing the algorithms), but with Reiser's tree algorithms you're probably spinning the disk less while waiting for the filesystem code to find the data you need.

      At any rate, full data journalling comes without the burden of "log what I'm going to do, complete with data, then perform the operations, then mark the pending operation as completed in the journal." Basically you get around having to write twice in nearly all cases.

      (If ReiserFS decides that it's a really really good idea to leave the data where it's at, it will write new contents to free space on the disk, update the tree to reflect the changes, write the new contents to the original file's location on the disk, and again update the tree. However, this only occurs in rare circumstances, and is the exception rather than the norm.)
  • by fiddlesticks ( 457600 ) on Saturday July 26, 2003 @01:49PM (#6540372) Homepage
    DELETE (time in secs to perform action)

    40.13(R4) 0.797 (ext3 journal) 0.837 (ext3)

    woo-hoo! now it corrupts my data even quicker :(
  • Which is best? (Score:3, Interesting)

    by Dodge This ( 654497 ) on Saturday July 26, 2003 @01:50PM (#6540373)
    OK so there seems to have been a lot of Reiser flaming going on here, so what would people recommend? Taking into account Speed, Reliability and Compatability.

    I know a lot of people will pull their hair out when they hear this, but: Speed is my primary concern. On long compiles of new programs or kernels for example the speed difference on a good FS can be important. I'm not saying that I'm willing to have a FS that corrupts every last file and directory, only that given two FSs which both have seemingly similar stability I would prefer the speed boost.

    I have tried one or two of the FSs but I haven't used them for any length of time to be able to compare one against another.

    • When you have a thousand machines, if you're constantly losing filesystems then you spend way too much SA time rebuilding them.

      of course if you've got a cluster of 100 machines that are all doing the same things and you can even make the app go 5% faster by a different filesystem, that can be a saving of $20,000 or so.

  • by Anonymous Coward
    In this [helsinki.fi] note, Hans Reiser clearly states his position: you trade off filesystem metadata performance against data integrity.

    Once you realize that this maintains your filesystem structure but turns your files into Swiss cheese (this happened to me several times) you'll switch to ext3 or XFS.

    Since reiserfs continuously rebalances the block tree, files that are only open for reading can be trashed by having a block exchanged with the last file written before a crash.

    Hans is recklessly pursuing optimization
    • Once you realize that this maintains your filesystem structure but turns your files into Swiss cheese (this happened to me several times) you'll switch to ext3 or XFS.

      That note just says what is common knowledge already, that if you want an actual crash proof system you need data journalling. I know very, very few people who use this, because it effectively means writing everything twice, which kills performance. That doesn't reflect upon ReiserFS at all, many filing systems don't support data journallin

    • by hansreiser ( 6963 ) on Saturday July 26, 2003 @03:15PM (#6540811) Homepage

      That was V3. V4 is an atomic filesystem, which means that every filesystem operation is performed as a fully atomic transaction. This is more secure than the guarantees of data journaling, as data journaling doesn't necessarily guarantee that the write will complete.

      The reason we are able to do this in V4 but not in V3 is that V4 uses what I call wandering logs. With wandering logs, instead of copying data first to the journal, and then after commit copying it from the journal to the rest of the filesystem, (thereby writing the data twice), we just change our definition of where the journal is. I don't think that data journaling is worth going half-speed for most users. With V4, we not only don't go half-speed, we go faster than V3 ever went.

      For more details, please take a look at http:www.namesys.com/v4/v4.html [namesys.com]

  • About reiser4 (Score:5, Informative)

    by Fefe ( 6964 ) on Saturday July 26, 2003 @01:58PM (#6540411) Homepage
    I attended Hans' presentation at Linuxtag.

    Basically, reiser4 is optimized for the case where you unpack a large tarball, say the Linux kernel, and have enough memory to hold it all in cache, which is true for most of us these days. reiser4 will then choose the optimal disk layout for these files and flush them to disk.

    Hans also has aspects of a log structured file system in reiser4, which means you don't write to the file, you write to a log file which basically encompasses the whole disk. The up side is that you mostly write linearly, the down side is that the files get badly fragmented if they are updated at all. Most files are not updated, just written once at installation of the package. The files that are updated frequently tend to be source code from CVS, which are small enough to fit in memory completely and have reiser4 choose an optimal disk layout again.

    The case where this model completely sucks is the case where you update many portions of a large file. For example, running an SQL database with files on a reiser4 file system as backend, or maybe a DNS server with DDNS, or a berkeley db backend for Postfix or qmail to keep the SMTP AUTH users or something. Also, log files will probably be badly fragmented.

    Hans proposes to have something like a transparent defragmenter running in the background, which he calls "repacker". This would run in the kernel space, as part of the file system, and defragment badly fragmented files that are accessed frequently. This would solve most of the down sides of his approach, but this repacker is not finished yet.

    My personal view of reiser4 is: it looks like it is optimized to perform well in benchmarks. It tries to be fastest for updating databases, but buys the performance by being slower when reading the data afterwards. The critical question is whether the repacker can alleviate these concerns, and as long as it is not finished, reiser4 is basically out of the question except for a little testing here and there. I reckon reiser4 would be a great filesystem for keeping your mozilla and gcc CVS checkout handy. But until the repacker is done, I will not even use it for testing, because the repacker really is the crucial component that makes or breaks this.

    By the way: my previous experiences with reiserfs were less than stellar. Some people call it shredderfs instead. The main complaint with reiserfs is and always was that the fsck is not nearly as trustworthy or stable as the one from ext2/ext3. So even if I use reiserfs at all, it's only for data I can afford to lose completely, like my CVS checkouts or the squid cache directories or something like that.

    The benchmarks do look good though, and I am glad that at least someone is still trying major innovations in this area. Since most Unix vendors or divisions are no longer profit centers, file system innovations have largely stalled or moved to specialized companies who regard them as proprietary (Veritas) instead of releasing them as free software like IBM and SGI did.
  • ext2? (Score:3, Interesting)

    by Coneasfast ( 690509 ) on Saturday July 26, 2003 @01:58PM (#6540412)
    I know ext2 isn't a journal fs, but it would still be interesting to see a direct comparison again reiser4.
  • by Anonymous Coward on Saturday July 26, 2003 @02:02PM (#6540433)
    It's still not time to swap it for ext3 for general use.

    The first table with the mixed file sizes is the most compelling. The fact that reiser4's Create and Copy times are less than a third of the ext3s in real_time is impressive.

    But the fact that the CPU consumption on Read is double that for R4 as it is for ext3 is a serious problem. On a 1.3 Ghz machine saturating a generic UDMA 100 60G bus on RH 9.0 it's about 10% of the CPU, so the home user might not care. For a system capable of delivering serious data (like a 4 drive, 15k rpm SCSI RAID array @~3 times the read throughput) going from 30% CPU to 60% CPU usage is a definite problem. Even with a 2.6 Ghz cpu it would still move from chewing up 15% to 30%. I know these numbers don't scale exactly, but they could in fact scale ugly depending on how much CPU is dedicated to communicating with the hardware and how much is in fiddling with the filesystem. My production boxes spend > 80% of their disk activity reading, so I'm not yet inspired to go out and spend the time running benchmarks on highperf. systems just yet.

    Nevertheless, I always admire it when a new version of software comes out and it's noticeably faster than the old

  • Real comparison? (Score:4, Insightful)

    by Quixote ( 154172 ) on Saturday July 26, 2003 @02:04PM (#6540440) Homepage Journal
    I'd like to see someone (i.e., not me) do a comparison of ReiserV4 with other heavy hitters like XFS [sgi.com] and JFS [ibm.com]

    That would be interesting.

  • In other news... (Score:4, Interesting)

    by wirelessbuzzers ( 552513 ) on Saturday July 26, 2003 @02:24PM (#6540512)
    Apple benchmarked their new G6 processor against the latest 10 GHz Pentium V. They say that despite its lower clock speed, it runs their suite of PhotoShop 8 filters almost four time faster than the Pentium.

    Seriously, Hans Reiser is benchmarking his own file system, and he's using benchmarks that make his system look good. Like the SpriteLFS, his filesystem has a log structure for sequential writing, which makes it look really good in tests like he performed where you write the files once.

    Compare a database load, where you write small chunks of big files all the time. Without the repacker (like the cleaner in LFS), the disk becomes horribly fragmented. With the repacker, you have to include the slowdown of this background process defragging your hard disk. Ick.

    I'll trust his benchmarks when he presents a final, stable release, with the repacker on, and tests it under workloads such as would be encountered on a server. I might use it on my homebox even if it sucks on a server, but it would be nice to know that he considers his structure's impact on other workloads.
  • linus (Score:3, Interesting)

    by austad ( 22163 ) on Saturday July 26, 2003 @02:25PM (#6540516) Homepage
    Didn't linus say no more new features at this point? Didn't Reiser try this same damn thing last time, fighting with the kernel people to get his stuff in after the feature freeze?
  • Should I bother? (Score:3, Interesting)

    by anthony_dipierro ( 543308 ) on Saturday July 26, 2003 @02:41PM (#6540606) Journal
    I'm not putting thousands of files in a single directory. I'm not using tons of small files, and my hard drives are more than big enough to hold my data. Is there any reason to use reiserfs instead of ext3?
  • Upgrading... (Score:3, Interesting)

    by SealBeater ( 143912 ) on Saturday July 26, 2003 @03:16PM (#6540820) Homepage
    What about upgradablity? The nice thing about ext3 is that upgrading to a new
    version is a reboot away. With ReiserFS, you had to re-format the drive, in
    order to upgrade. Has this changed?

  • by Pflipp ( 130638 ) on Saturday July 26, 2003 @04:40PM (#6541224)
    I have some questions abou ReiserFS and was wondering whether someone out there would be able to answer them.

    First off, there's this stuff with ReiserFS storing fine-grained data. Does this imply that using ReiserFS (v3 or v4) directly as a database would be efficient? I know RFS doesn't have Relational features, but these might very easily be implemented in userspace if you can store e.g.: .../customers/0001/name .../customers/0001/phone .../customers/0001/agent -> .../personnel/0021

    Am I losing this or getting this???

    My other question was about this metadata-as-file thing. Hans can implement whatever he wants, but it just so appears that Linux behaves like Unix. I've just made a ReiserFS partition to check, and there's no way I can "touch foo; ls foo/" to see e.g. permissions etc.

    Now I'm aware that this might be v4 stuff, but I wonder if anything of this is ever to be seen back in Linux userland? E.g., will it be possible for projects to use ReiserFS to change the paradigm used for metadata using a straight Linux kernel?

    See, from time to time I just happen to be quite impressed with the "everything is a file" applied to metadata, and I hope we can make the shift to this future one day, and finally get rid of file extensions, MIME guesses and app association registries in Linux, and store this stuff in metadata space.
    • by hansreiser ( 6963 ) on Sunday July 27, 2003 @03:39AM (#6543446) Homepage
      I get reports (not verified by me) that ReiserFS V3 is an order of magnitude faster when used as a backend for an XML database than relational databases that were tried. So, if your data happens to have a hierarchical structure, or, you can put it into one, then you are likely to get a performance gain. If your data does not have a hierarchical structure, then you need to wait for V6 where we plan to expand the semantics.

      If you want to be able to "cat filenameX/..owner" to see who owns "filenameX", you need to use V4.

This universe shipped by weight, not by volume. Some expansion of the contents may have occurred during shipment.