Please create an account to participate in the Slashdot moderation system


Forgot your password?
Data Storage Software Linux

Reiser4 Filesystem Released 637

trixie_czech writes "It's finally arrived. Go to namesys for reasons to use reiser4 as a filesystem and benchmarks. Go here to download. Enjoy!" The Namesys homepage in its current stage reminds me of a cross between The Secret Guide to Computers and the GNU Manifesto -- which is to say, there is a lot to read here, not just a bullet-pointed feature list.
This discussion has been archived. No new comments can be posted.

Reiser4 Filesystem Released

Comments Filter:
  • ext3 to reiser4 ? (Score:4, Interesting)

    by Anonymous Coward on Monday August 23, 2004 @10:23PM (#10052440)
    Will I be able to convert my exsisting ext3 fs to reiser4 fs withou having to reformat?
    • Re:ext3 to reiser4 ? (Score:5, Informative)

      by Aardpig ( 622459 ) on Monday August 23, 2004 @10:26PM (#10052467)

      Will I be able to convert my exsisting ext3 fs to reiser4 fs withou having to reformat?

      No, you will have to reformat. However, I recommend the upgrade; I've seen a number of studies showing that the performance of ext3 is awful compared to reiserfs. The only arguable advantage of ext3 is its compatibility with the baseline ext2.

      • by treat ( 84622 )
        No, you will have to reformat. However, I recommend the upgrade; I've seen a number of studies showing that the performance of ext3 is awful compared to reiserfs. The only arguable advantage of ext3 is its compatibility with the baseline ext2.

        ext3 has fewer bugs and has been through more testing. ext3 has a functioning fsck, reiserfs does not.

        For most applications the reliability of the filesystem is far more important than the performance.

        I'm definitely excited about reiser4 but I don't expect to be

        • Re:ext3 to reiser4 ? (Score:5, Informative)

          by Aardpig ( 622459 ) on Monday August 23, 2004 @10:43PM (#10052603)

          ext3 has a functioning fsck, reiserfs does not.

          I myself have never had any problems with reiserfsck -- what exactly is wrong with it?

          • by Anonymous Coward on Tuesday August 24, 2004 @12:05AM (#10053013)
            I myself have never had any problems with reiserfsck -- what exactly is wrong with it?

            You don't know? The problem with reiserfsck is that it is invisible to those who are dogmatically anti-Reiser. Hans is currently working on a ReiserDecloak() function to address this.
        • Re:ext3 to reiser4 ? (Score:5, Informative)

          by 13Echo ( 209846 ) on Monday August 23, 2004 @11:16PM (#10052793) Homepage Journal
          ext3 has fewer bugs and has been through more testing. ext3 has a functioning fsck, reiserfs does not.

          "man reiserfsck"

          But ReiserFS doesn't need an "fsck" type program in normal circumstances. In power outages, etc., it's rock-solid. But for things like drive failures and the likes that tend to actually corrupt the data, then yes; EXT3 is the better choice. The reiserfsck program isn't intended to be run on the event of just any power outage or failed unmount, because those sorts of things don't tend to damage the filesystem.

          I've been using ReiserFS 3 for years and I've really been happy with the results. The only times (once or twice) that I've had problems were when I had severe hardware malfunctions (due to failing mobo capacitors and a dying hard drive), and my own carelessness when trying to repair the bad data.
          • Re:ext3 to reiser4 ? (Score:5, Informative)

            by SaDan ( 81097 ) on Monday August 23, 2004 @11:48PM (#10052950) Homepage
            I've successfully recovered a trashed array running ReiserFS after losing a CPU.

            reiserfsck is there, and does work.

            I've had more problems with the Ext filesystems than I care to mention, and we do not use Ext2 or Ext3 on any production machines that run Linux any more. Everything's ReiserFS v3, and once we start testing Reiser4, we'll move to that.

            Ext3 was a hack for compatibility with Ext2. It serves its purpose, which is easy upgrades and backwards compatibility.
    • by Dwonis ( 52652 ) * on Monday August 23, 2004 @10:28PM (#10052483)
      I doubt it. In general, that's not necessarily possible (though you can get away with it in special cases). In any case, doing that without a UPS would probably be risky, since there would be a (probably very long) period of time where the filesystem is totally incomprehensible to BOTH filesystem drivers (old and new), and if the system dies during that time, say bye-bye to your data.
    • Re:ext3 to reiser4 ? (Score:5, Informative)

      by David M. Andersen ( 711958 ) * <> on Monday August 23, 2004 @10:28PM (#10052486) Homepage

      Possibly using convertfs [], but I have no idea if it works or not.

      This page [] seems to have more info about it.

      • Re:ext3 to reiser4 ? (Score:5, Informative)

        by EMN13 ( 11493 ) on Monday August 23, 2004 @10:46PM (#10052624) Homepage

        Nope convertfs won't work... From the horses mouth:

        To upgrade from reiserfs V3 to V4, use tar, or sponsor us to
        write a convertfs.

        The lkml posting is probably cached all kinds of places, but kerneltrap [] also reproduces it in full.

        Then again, reiserfs v4 and v3 have nothing to do with each other (unlike ext2 and ext3 for instance), so there's no quick fix possible probably.

        On the other hand - reiser4 is completely untested (compared to reiser v3 and jfs, xfs, ext2, heck even the wine-dll emulation layered ntfs writing driver...), so do yourself a favour and don't do anything quite so crazy as not just using it for a production machine but also trying to convert an existing system to it with 'smart' tricks... Give it a little while... or make a lot of backups...

  • Windows port? (Score:3, Interesting)

    by Anonymous Coward on Monday August 23, 2004 @10:24PM (#10052441)
    Will we ever have a Windows port of ResierFS or any alternative filesystems?
    • Re:Windows port? (Score:5, Informative)

      by Coneasfast ( 690509 ) on Monday August 23, 2004 @10:28PM (#10052481)
      there is rfstool [] for reiserfs (afaik not v4)
      and many [] for [] ext2/3 []

      if OTOH, you are looking for a fully featured driver that can be used for production use, then i wouldn't count on it
    • Re:Windows port? (Score:5, Informative)

      by Aardpig ( 622459 ) on Monday August 23, 2004 @10:31PM (#10052507)

      Will we ever have a Windows port of ResierFS or any alternative filesystems?

      I'm not sure about ReiserFS, but there is already a program -- Explore2fs -- which lets you mess around with Ext2 and Ext3 partitions from Windows. Why you would want to do that is beyond me, but there you go.

      Of course, you may be talking about a native Windows implementation of Ext2/3 and/or ReiserFS. Which is a totally different kettle of fish...

      • Re:Windows port? (Score:3, Informative)

        by Daverd ( 641119 )
        I'm not sure about ReiserFS, but there is already a program -- Explore2fs -- which lets you mess around with Ext2 and Ext3 partitions from Windows. Why you would want to do that is beyond me, but there you go.

        I have a hard drive with Windows installed on it and a hard drive with Linux, and I use both OSes. Explore2fs is handy when I'm in Windows but I need to grab a file on my Linux drive.
    • Re:Windows port? (Score:3, Insightful)

      by Stevyn ( 691306 )
      You're talking about porting a file system assuming the operating system is unaware of it. We can look at the source code and linux and find that answer out, but with windows it's more difficult to tell. Since Microsoft seems to only support FAT, FAT32, and NTFS, I'm sure that's built into the kernel for speed. So unless you're going to make something that emulates NTFS on top of reiser, I doubt it would ever work. And if you're going to do that, what's the point at the end of the day?

      For windows and l
    • Re:Windows port? (Score:3, Informative)

      by j3110 ( 193209 )

      works for me now.... I have to say I would much prefer a real driver, but beggers can't be choosers.
  • by fishbert42 ( 588754 ) on Monday August 23, 2004 @10:24PM (#10052449)
    ... but can they tango?
  • Only one question... (Score:4, Interesting)

    by Pathway ( 2111 ) <> on Monday August 23, 2004 @10:26PM (#10052462)
    I only have one question (And I obviously have not researched an answer...):

    Is there an easy and non-destructive way for me to migrate my ReiserFS version 3 to a version 4 Filesystem?

  • by moosesocks ( 264553 ) on Monday August 23, 2004 @10:27PM (#10052470) Homepage
    but will it save Namesys from a slashdotting?

    Seriously.... their server admins must be FSCKing angry.
  • Helpful Mirror (Score:4, Informative)

    by Anonymous Coward on Monday August 23, 2004 @10:29PM (#10052493)
    Reasons why Reiser4 is great for you:

    * Reiser4 is the fastest filesystem, and here are the benchmarks.
    * Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don't, and they don't corrupt due to half occuring. We do this without significant performance losses, because we invented algorithms to do it without copying the data twice.
    * Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down). This makes Reiser4 more space efficient than other filesystems because we squish small files together rather than wasting space due to block alignment like they do. It also means that Reiser4 scales better than any other filesystem. Do you want a million files in a directory, and want to create them fast? No problem.
    * Reiser4 is based on plugins, which means that it will attract many outside contributors, and you'll be able to upgrade to their innovations without reformatting your disk. If you like to code, you'll really like plugins....
    * Reiser4 is architected for military grade security. You'll find it is easy to audit the code, and that assertions guard the entrance to every function.

    V3 of reiserfs is used as the default filesystem for SuSE, Lindows, FTOSX and Gentoo. We don't touch the V3 code except to fix a bug, and as a result we don't get bug reports for the current mainstream kernel version. It shipped before the other journaling filesystems for Linux, and is the most stable of them as a result of having been out the longest. We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3.

    • Sure, the text might be helpful, but I think much of the value of this article comes from the images that go with it. E.g., this one [].

      No, really, they use a bunch of illustrations like this in the linked article. It dumbfounds me.
    • Re:Helpful Mirror (Score:5, Insightful)

      by PingXao ( 153057 ) on Tuesday August 24, 2004 @02:12AM (#10053567)
      "Reiser4 is architected for military grade security."


      Alarm bells going off here. There is no commonly accepted definition of what constitutes "military grade security". Authors and vendors should avoid this terminology like the plague. It reeks of snake oil and most security profressionals will look askance at anything that touts this "feature". Having said that, I've used Reiser3 and I think it's great. There's no reason to think Reiser4 won't be even better. Given its plugin architecture there's also no reason to think that secure plugins can't be developed for it in a transparent way that actually provide good security. Maybe my complaint here is pedantic. Never say never, but no software program should ever use the phrase "military grade security" if it wants to be taken seriously. There is no standard of "military grade security" by which such claims can be measured. Why would you want your software to be grouped with fraudulent security products, even if yours really is secure.
  • by Elote ( 649512 ) on Monday August 23, 2004 @10:34PM (#10052533)

    I did an informal comparisson of this fs against several others for one of my classes, and my results had it winning _hands down_.

    But on a more serious note, I hope this release is stable. From lurking on their mailing list, it seems that it hasn't been too long since they were in bug-squashing mode.
  • by Stevyn ( 691306 ) on Monday August 23, 2004 @10:35PM (#10052543) use it for a while. I'm sure it's been tested very extensively, but there are always bugs initially in any major release like this. I'm sure nobody running a server will touch this for a while even with the benchmarks.

    I'm not trying to spread FUD on reiser at all, I run reiser 3 and I've never had any problems. I'm just raising the question of how long does it take until people will put it in production servers and their main desktops?

    Anyone who maintains servers care to shed some light on this?
    • by dtfinch ( 661405 ) * on Monday August 23, 2004 @11:06PM (#10052753) Journal
      When deciding which filesystem would be best for our first critical samba file servers, this post and other scattered rumors of unreliability scared us away from reiser3 for the time being: ly/msg00418.html []

      The date of the post caught my eye. The test was very recent. Ext3 won in this particular case, by a longshot, leading a Red Hat employee to respond "Your investigation proves that we default to the right mode ;)".

      I haven't seen ext3 (ordered) lose in any reliability benchmarks versus jfs, xfs, or reiserfs, though it's hard to find many such benchmarks.
      • by SaDan ( 81097 ) on Monday August 23, 2004 @11:44PM (#10052934) Homepage
        It hasn't been my experience that ext2 or ext3 filesystems are more reliable than ReiserFS. At least, not where I work (I only run ReiserFS at home).

        Over the past year, we've had some fairly serious filesystem failures on some of our DB and large FS servers. Ext3 on failed in every instance, Reiser was recoverable (similar RAID/hardware/useage/failure).

        We pound the living hell out of our machines, day and night, with billions of small files every year. ReiserFS makes Linux work for us.

        There are some instances where ReiserFS v3 is slower than Ext3, but we don't care about that any more. We're finished with Ext2/3, and are looking forward to testing ReiserFS4 now that it's been released.
      • by uhoreg ( 583723 ) on Monday August 23, 2004 @11:54PM (#10052973) Homepage
        That's old news. That particular case of ReiserFS corruption is due to the fact that ReiserFS (until a little while ago) only did metadata jounalling and did not ensure that data is written before metadata. The problem could have been fixed by applying a well-known patch (at least well-known among the ReiserFS community), which has recently been merged into the mainline kernel (at least the 2.6 series, though I'm sure 2.4 has it too).

        Reiser4 does not have such a problem, as it operates in data=ordered mode by default.

      • by hansreiser ( 6963 ) on Tuesday August 24, 2004 @04:40AM (#10053967) Homepage
        Keep in mind that redhat kernels are highly patched and they don't apply reiserfs bugfix patches out of a deliberate policy to exclude them (yes, we offered to supply them but were rejected), so we don't recommend the use of redhat kernels for reiserfs, we recommend the official kernel, or the SuSE kernel.

        RedHat are the guys that at one point shipped their kernel with REISERFS_DEBUG turned on just to make us look slow.....

        I don't know why RedHat regards us as in the enemy SuSE camp just because we took money from SuSE, we would take money from RedHat too if it was offered....;-)

        These distro rivalries are distasteful to me.

  • by Chordonblue ( 585047 ) on Monday August 23, 2004 @10:36PM (#10052553) Journal
    There doesn't seem to be a Windows version of Reiser on that li....


  • by TigerTime ( 626140 ) on Monday August 23, 2004 @10:41PM (#10052587)
    "The Namesys homepage in its current stage is reminds me of a cross between The Secret Guide to Computers and the GNU Manifesto " Yea, i see "This page cannot be found" on alot of websites
  • Stability (Score:3, Insightful)

    by Anonymous Coward on Monday August 23, 2004 @10:42PM (#10052595)
    I remember reading something a while back about how ReiserFS would occasionally barf and corrupt data... And that the Dev response was something to the effect of 'so what?'.

    How stable in this new version in terms of data loss? Is this something that's optimized to run on a RAID array--with, say mirroring--that gets it's speed from dangerous shortcuts that are only acceptable in a non-single-disk environment?
    • Re:Stability (Score:5, Insightful)

      by Wesley Felter ( 138342 ) <> on Tuesday August 24, 2004 @12:06AM (#10053027) Homepage
      If your filesystem has bugs, no amount of RAID will save you.
    • Re:Stability (Score:5, Informative)

      by hansreiser ( 6963 ) on Tuesday August 24, 2004 @03:22AM (#10053761) Homepage
      Our response is definitely not so what. We might have told you that metadata journaling (what V3 uses) provides a level of service in which, like FFS and many other filesystems before it, if you crash during a write the write gets garbled.

      Reiser4 is fully atomic though, and a write will either make it to disk entirely or not at all, with no data garbling. In other words, assuming that metadata journaling was what made you unhappy, we listened, but waited until a deep rewrite could allow us to fix it with no significant performance loss.

      We are very happy that the use of wandering logs allowed us to make things atomic without losing any significant performance.
  • by blackketter ( 72157 ) * on Monday August 23, 2004 @10:43PM (#10052599)
    IF you can get to the site, you'll find this juicy reference at the end:


    "Inside the Windows NT File System" the book is written by Helen Custer, NTFS is architected by Tom Miller with contributions by Gary Kimura, Brian Andrew, and David Goebel, Microsoft Press, 1994, an easy to read little book, they fundamentally disagree with me on adding serialization of I/O not requested by the application programmer, and I note that the performance penalty they pay for their decision is high, especially compared with ext2fs. Their FS design is perhaps optimal for floppies and other hardware eject media beyond OS control. A less serialized higher performance log structured architecture is described in [Rosenblum and Ousterhout]. That said, Microsoft is to be commended for recognizing the importance of attempting to optimize for small files, and leading the OS designer effort to integrate small objects into the file name space. This book is notable for not referencing the work of persons not working for Microsoft, or providing any form of proper attribution to previous authors such as [Rosenblum and Ousterhout]. Though perhaps they really didn't read any of the literature and it explains why theirs is the worst performing filesystem in the industry....
  • Well? (Score:3, Funny)

    by iamdrscience ( 541136 ) on Monday August 23, 2004 @10:45PM (#10052618) Homepage
    Somebody post a bulleted list of featuress already! I'm a busy man, I don't have time to read anything longer than two and a half pages of double-spaced 12pt Courier, and that's only for the executive summary of my encyclopedia A-L anyways.
  • Sweet! (Score:3, Insightful)

    by chizu ( 669687 ) on Monday August 23, 2004 @10:50PM (#10052644) Homepage
    Now when will we see it in the vanilla kernel?
  • by Anonymous Coward on Monday August 23, 2004 @10:53PM (#10052673)
    I'm going to stick w/ Emacs for my filesystem thank you.
  • by dekeji ( 784080 ) on Monday August 23, 2004 @10:57PM (#10052697)
    ReiserFS is great, and this seems like a tasteful way of implementing some of the complex things people seem to want to do with file systems.

    But I would feel uncomfortable relying on any of these features right now because any software that does would fail with any other file system. ReiserFS is free software, but you still end up needing to run software on other file systems in many cases.

    I think for these features to become widely adopted, we need some kind of library-based emulation, something that uses ReiserFS if it runs on it and otherwise emulates ReiserFS features like files-as-directories in user mode on top of existing file systems (by using funny file names, etc., similar to UMSDOS).
  • MANIFESTO (Score:3, Funny)

    by YetAnotherName ( 168064 ) on Monday August 23, 2004 @11:05PM (#10052747) Homepage
    Yes, that certainly comes across more like a manifesto than a detailed exposition of software architecture. I have to admit, reading through it, my KOOK Alert was almost reaching critical stages ... if they only included SOME ALL CAPS SECTIONS as well as a reference to Einstein, who was on the brink of making a similar discovery, but was forced to suppress it DUE TO GOVERNMENT INTERVENTION, then the KOOK alarms would be blaring and I'd've discounted the entire thing.

    Now, all I'm interested in doing is exploring the potential of doing everything in the "manifesto" literary style. My next letter to the editor? Manifesto. My thank-you note to grandma? Manifesto. My resume? Manifesto. My next Slashdot posting? Manifesto.

    Oh yes ... they never trusted me at the academy ... but they'll learn the hard way ... mwuahaha, er ... ha.
  • by SteamyMobile ( 783822 ) <> on Monday August 23, 2004 @11:10PM (#10052770) Homepage
    Finally, we have a way of having an encrypted FS in Linux that's not an ugly kludge like loopback. The modular system is great because we can add encryption, access control, all kinds of things without having to go through the trouble of writing an FS from scratch.

    It's very disappointing that it took Linux all these years to get something as basic as a secure, encrypted way to store files. Even Windows has had FS encryption for a while.

    The next release of Suse is going to be a doozy. KDE 3.3, Reiser 4.

    • Uh, excuse me? (Score:5, Informative)

      by Lethyos ( 408045 ) on Tuesday August 24, 2004 @12:24AM (#10053102) Journal
      Finally, we have a way of having an encrypted FS in Linux that's not an ugly kludge like loopback.

      I think you misunderstand, that's the beauty of it. Basically, Linux (and FreeBSD with GBDE []) allows you to encrypt a device at the block level. Everything is written to the disk encrypted, including the file system itself and not just the data. This also allows you to abstract the device. It could be a big file sitting on an existing device or the device itself. It's very flexible.

      Some of the other advantages of this are fairly important. Here's a few off the top of my head.

      1. It is easier to build a more secure and more reliable encryption system that works with all means of storing to a device rather than an encryption system for every one of those means. (1 versus an arbitrary number.) To simplify to more practical terms, it is better to write one encryption mechanism that can work with 10 file systems rather than 10 encryption mechanisms to work with each of those.
      2. If you want to encrypt data, you might not always be writing a filesystem to a device. If I have a database that makes raw access to a device for its storage, but I want encryption, I need it at the block device level.
      3. You do not want to make the file system any more complicated than it needs to be. Adding encryption would produce a disaster. Aside from making it easier to corrupt data, you lose a great deal of performance and security. How? Let's say you encrypted your data and sorted or indexed it by the plaintext. You are giving lots of clues to a potential attacker regarding the contents. If you do not follow this convention, you have to decrypt every byte to figure out whether or not its what you want. Horrible! (This may be an over-simplification. Anyone care to check me on this? Still, the basic principle should apply.)
      4. Keeping encryption outside the filesystem makes it easy, even trivial to arbitrarily choose the cypher, the key size, and even the block size. The filesystem would undoubtably impose limitations on all these choices if the encryption were built in.

      On the plus-side, filesystem level encryption lets you choose to encrypt on an as-needed basis (such as with NTFS), but the uses of this are minimal and questionable at best (what about swap, temporary files, and data that you forget to encrypt?)

      all kinds of things without having to go through the trouble of writing an FS from scratch.

      I think you may have learned from my previous comments how you accomplish this. Hint: you don't encrypt at the filesystem layer.

      It's very disappointing that it took Linux all these years to get something as basic as a secure, encrypted way to store files. Even Windows has had FS encryption for a while.

      Using the loopback device to encrypt data has been available for longer than NTFS has had encryption.

      • by 0x0d0a ( 568518 ) on Tuesday August 24, 2004 @04:20AM (#10053903) Journal
        There are also some severe disadvantages to block-level encryption -- from a user standpoint, WinNT-style filesystem-level encryption is generally preferable. Among other things:

        * Filesystem-level encryption can outperform block-level encryption.

        * It's easy for a Windows NTFS user to "start encrypting something" -- they right-click a directory and check a box. Linux requires a new mounted filesystem running through a new loopback device. Since this isn't doable at the user level in any distro that I'm aware of, it pretty much means that each user doesn't have their private files encrypted separately.

        * Choosing as-needed performance is not trivial. I currently maintain individual files encrypted with GPG. I don't want to have to have my P2P software making my kernel blow cycles constantly and unnecesarily encrypting and decrypting software.

        * Unless I'm doing something really grotty, like putting a filesystem on block-level encryption on an LVM virtual volume, if I'm using block-level encryption, I'm forced to choose how much space to allocate to each encrypted area -- how much to put towards my ~/.private directory, how much to put in my ~/main/notes/passwords directory, and so forth. If I'm using filesystem-level encryption, I'm taking available space from a shared pool.

        * While not strictly a block-level vs filesystem-level encryption issue, no major distro that I'm aware of provides a nice interface for setting up encrypted directories (well, mount points with block-level encryption) and home directories, with a user's login password used to decrypt keys used to access the encrypted filesystems. Windows is significantly more user-friendly (including providing the option of administrative key recovery) here.

        The block-level approach is ideologically clean and modular, but has serious drawbacks. It cannot replace filesystem-level encryption.
  • Transactions? (Score:5, Interesting)

    by ceswiedler ( 165311 ) * <> on Monday August 23, 2004 @11:29PM (#10052871)
    How large (and long) can Reiser atomic transactions be?

    Can I write an installation program which creates, replaces, moves, and deletes many files and directories, and have it all be under one transaction with a single commit at the end? Do other 'sessions' not see the transaction until it is complete? Are sessions based on processes or threads or something else?

    That would be pretty amazing, to be able to roll back large sets of changes in case of an error. I know that database rollbacks can take large amounts of time (they optimize for the commit, which makes perfect sense) but nonetheless having rollback support in applications would be sensational.
    • Re:Transactions? (Score:5, Informative)

      by hansreiser ( 6963 ) on Tuesday August 24, 2004 @02:49AM (#10053680) Homepage
      Our atomicity does not provide isolation or rollback, it is only atomic in the sense of whether it survives a crash. That is, a reiser4 atomic set of operations will either all survive the crash or none of them will.

      You can say that this is not really atomic, and by database traditions that is correct, but I believe we have implemented the aspect of atomicity that for sure should be implemented by the file system and not by the layers above.

      Later we may support more isolation and rollback, but we started with allowing people to define a set of fs modifying operations that would either all be preserved across a crash or none of them would be preserved. I tried using the term "transcrash" instead of atom, but no one but me loved the term.

      I must caution though that the API for defining an atomic set of filesystem operations is still being debugged. The core infrastructure is rock solid though, as it is what we use for atoms defined internal to the FS. We shipped as soon as our core code was rock solid, and plan to incrementally finish the other stuff over the coming year.
  • User Report (Score:3, Informative)

    by vandan ( 151516 ) on Monday August 23, 2004 @11:30PM (#10052881) Homepage
    I've been using reiser4 for quite some time here at work. I'm booting from a 'redeeman' boot disk ( Gentoo hacker ) and then installing Gentoo unstable onto our work PCs :)

    It rocks. Very, very fast. Whereas an:
    emerge -up --deep system

    would have taken about 20 seconds to run under reiser3, it takes about 5 seconds under reiser4. Very impressive.

    I haven't had any stability issues with it. There were ( last time I checked ) 2 outstanding bugs - one nfs ( files on server with reiser4 ) bug, and one strange bug that made adn OpenOffice compile fail miserably. Bug (1) doesn't affect us, as our nfs server is running reiser3, and bug (2) I got around by creating a reiser3 partition, mounting /var/tmp/portage on it, emerging OpenOffice, and building a package of it for all the other PCs.

    I just can't get over how fast it is.
  • by bulletman ( 254401 ) on Monday August 23, 2004 @11:47PM (#10052942)
    Over the past few days (ever since reiser4 was accepted into the mm kernels) I've been looking for a boot CD with reiser4progs 1.0. I want to try reiser4, but need a boot CD to format my new drives and mount my current partitions for copying.

    The only boot CD I was able to find was the (R)ecovery (I)s (P)ossible Linux rescue system: in ux/rip/

    It was released yesterday (22 Aug) and is still warm to the touch.

  • by squidinkcalligraphy ( 558677 ) on Tuesday August 24, 2004 @12:24AM (#10053103)
    This looks very cool.

    Using files are both files and directories is really nice - throw ACLs, metadata, whatever in a directory the same name as the file: access it as a file and it is the file, access it as a directory and it provides access to the metadata. It doesn't break things. Well, not much. As mentioned, this will break things like tar a bit. But the VFS has managed to deal with resource forks from HFS, albeit in a slightly ugly fashion. This is a little nicer, and perhaps with time will be the framework for slowly abandoning outdated filesystem concepts.

    How would you mofidy tar to deal with this? Add a .reiser_meta folder in each directory to store the corresponding file directories? Or is there another way?
  • by mcrbids ( 148650 ) on Tuesday August 24, 2004 @01:44AM (#10053461) Journal
    There are two kinds of people, when it comes to the original VW Beetle: Those who love them, and those who hate them.

    People who do not fall in one of the above two categories have never really used or owned an original VW Beetle.

    It seems filesystems are the same way. I'm a long-term Ext2/3 user and have never had any particular issue with it. For the medium-power stuff I work with, it does fine. The filesystem on my laptop has been ext2/3 for almost 5 years now, I still have email, documents, etc. from 5 years ago on it. (It's been copied a few times - it originated on an AMD K6 system, now it's on a Dell Centrino Laptop)

    So, I guess I'm in the "Ext3 is all good" camp.

    Reading these posts, there are those who love Reiser, and those who hate it. Those in the middle haven't apparently used it.

    I've found Ext3 to be slow when you have more than about 5000 files in a directory. If I had a specific need for that, I'd consider Reiser if my particular distro (RedHat migrating to Debian) supported it "out of the box".

    Other than that, why bother? I've delivered millions upon millions of email messages and many millions of website hits on servers running Ext3.

    So, for me, what filesystem I use is sort of like what tires I use on the car. I might care slightly when installing, but otherwise I wouldn't give even a rat's ass.
  • One of the things I still miss most under Linux are a proper trashcan/undelete (at filesystem level, not at GUI level that doesn't help on the shell) or even better a full blown 'undo' operation on the filesystem. Even MSDOS provided a very basic undelete operation and I can't really believe that we are still without it on Linux.

    Does ReiserFSv4 provide stuff like that? Or in case it don't, are the 'Plugins' that it supports
    powerfull enough for that and are there maybe already plugins awailable that add an undelete/undo? Better yet would of course be a fullblown versioned filesystem, how about that, is that doable with ReiserFSv4 plugins?

    And how do the plugins relate to for example GNU Hurds translators or LUFS? Do they act at a similar level, or are they completly different?
  • German magazine iX (Score:4, Interesting)

    by MemoryDragon ( 544441 ) on Tuesday August 24, 2004 @09:08AM (#10054968)
    Ran a huge article on Reiser4 a while ago. (Around 2 issues ago)
    They said it was blazingly fast, but had problems, that the performance went down the drain once the processor did something not reiserfs related, thus IO is a higher burden on the processor, due to the tree structure they use.

    The other problem is fragmentation, which should be resolved by a defrag daemon/tool running in the background, which was not available back then.

    So my question, have those two problems been resolved already?

If graphics hackers are so smart, why can't they get the bugs out of fresh paint?