Slashdot Mirror

← Back to Stories (view on slashdot.org)

Rewritten ReiserFS 4 Promises 2-5x Speed Increase

Posted by timothy on from the mounting-tension dept.

An anonymous reader reports that version 4 of "ReiserFS will be released in first quarter. Complete rewrite will support Atomic writing. 2-5 times faster. File corruption will be a thing of the past. Lindows.com is paying for part of it."

4 of 82 comments (clear)

  1. More info by ttfkam · · Score: 4, Informative
    A link to the main project page can give more info.

    Or if that is too much to digest, I wrote a fairly easy to follow summary on kuro5hin.

    --

    - I don't need to go outside, my CRT tan'll do me just fine.
  2. Re:Reiser? Is that you? by ceej · · Score: 4, Informative

    Yes-- this is far too late to save ReiserFS on my installation. I moved all our disks to ext3 a few months ago after experiencing extensive file corruption. A scsi disk went bad. When it went down, all files that had been active at the time were corrupted. Mostly that was several dozen mail spool files. Didn't I switch to a journaled file system in part to avoid this sort of thing? Grrrrrrrrrr.

  3. Re:Reiser? Is that you? by LarryRiedel · · Score: 4, Informative
    A scsi disk went bad. When it went down, all files that had been active at the time were corrupted. Mostly that was several dozen mail spool files. Didn't I switch to a journaled file system in part to avoid this sort of thing?

    Both ext3 and reiser3 offer(ed) data journaling, which would help with that kind of thing. Neither of them would even try to provide any better protection against corruption than if the application program(s) crashed. If a drive failed while applications were writing to files, the files might be current as of the most recent completed system call (write() or whatever), but even then, they could be "corrupt" in the sense that not all the operations in a sequence had completed; I do not think even reiser4 offers that level of transactional support-- I guess maybe it could have some sort of open()...close() atomicity thing, which would be nice.

    Larry

  4. That's because of metadata journaling by r6144 · · Score: 4, Informative
    Reiserfs3 does metadata journaling only, which only makes sure that the filesystem itself doesn't become b0rked (so that you don't have to run "fsck" during reboot) when the system goes down suddenly. It doesn't protect the data in your files. It is quite possible that the system wrote the information "the 3rd block of /var/spool/mail/xxx is the 1134th block on the filesystem" onto the disk, but the system crashed before the 1134th block is actually written to (the data blocks are not journaled; this is metadata journaling), so the 3rd block of that file becomes garbage.

    Ext3 in its default mode also does metadata journaling only, but it always writes the data blocks first (at some performance hit), so such lossage won't occur.

    In theory, you may lose data badly during a power failure on a non-journaling filesystem such as ext2, since the filesystem itself may be badly broken. However, this does not occur often in practice.

    In short, reiser3 is probably not the data-eating monster in normal operating conditions, nor will the filesystem become corrupted in case of a power failure, but newly rewritten data can get lost (including the older versions) during a crash or power failure, so it is probably safer to use ext3 for now if you don't have a UPS. Also, if your disk fails, all bets are off --- expect to lose some data, no matter how advanced your filesystem is (unless it is designed to operate on faulty hardware).

    BTW, I dumped reiserfs on my disk (on my home machine) during a disk failure because it doesn't have the feature to mark blocks as "bad". Quite a few blocks on my disk mysterically went bad, and for some reason it was not corrected by the hard drive.