ReiserFS? How reliable is it? Is this the future?

Hi folks,

If I get the DVD stuff working, then I won't need NT anymore, i.e. I will have an empty disk.

What is your impression about ReiserFS? Does it work? Is it stable enough for my daily work, or is it something to try out and watch carefully? Do you use ReiserFS for your boot partition?

Or should I try ext3 instead?

Regards

Harri

I am using reiserfs since kernel 2.2.14 or so.
It runs on my IBM Thinkpad without complications with kernel 2.4.3. Same with a Compaq Proliant Server, kernel 2.4.2-ac28, two PIII and a hardware raid controller. I heard about complications with nfs. I cannot see any speed improvements (maybe there are some beacause of the tree structure) but the file system check after a crash is much faster than with ext2.
It would be nice, if there are any hackers from the xfs, ext3 or jfs development team with some comparisons.

ff

Frank Fiene, SYNTAGS GmbH, Im Defdahl 5-10, D-44141 Dortmund, Germany
Security, Cryptography, Networks, Software Development
http://www.syntags.de mailto:[email protected]

My Linux boxes are 99% Reiserfs (I work with 2 small ext2 partitions - the rest are Reiserfs partitions). Some things I have noticed:

The good (2.2 kernels):

* No problems at all using Reiserfs 3.5.x on 2.2 kernels
* Speed improvements using Reiserfs and squid
* No NFS problems
* Rollback of logs is extremely fast vs. fsck

The bad (2.2 kernels)

* Nothing I can think of

The bad (2.4.x kernels):

* Some corruption problems with various 2.4.x kernels, but people are reporting ext2 problems, too, so this is probably due at least in part to IDE/PCI chipset issues
* Some corruption problems if an application
uses an nfs-mounted reiserfs partition during
an unexpected shutdown of the nfs server

The good (2.4.x kernels)

* Reisefsck --rebuild-tree works fine for me
when I get corruption problems

I haven't used Windows to do any work in years. Just games.

-Nick

**********************************************************
Nicholas Petreley   Caldera Systems - LinuxWorld/InfoWorld
[email protected] - http://www.petreley.com - Eph 6:12
**********************************************************
.

Security exploit according to bugtraq, but Im pretty sure it wont take Chris Mason and friends long to fix that.

With the latest tail fixes Im fairly sure the remaining corruptions are not reiserfs specific - but not yet 100% confident.

(You want the NFS patches too)

I use reiserfs on
a) P3(450) machine 440BX/ZX Chipset 82371AB PIIX4 IDE UDMA33
b) athlon(1100) VIA KT133 something IDE UDMA33

On both of them i have spurious small file garbage problems during compiling.

There was no situation with real trouble, no permanent damage, restarting the job solved the problem all the time.

I could not find a real corrupt file on disk.
It seems to me like the corruption happens in memory only. (just an impression)
The machine with less memory triggers it more likely.

On 2.4.3-pre6 a file that has not been changed for months was sometimes not found.

I have no problems on the ext2 partitions.

I've had 0, Ziltch problems with ReiserFS at the moment. It's solid for me.

Hi Harald,

For me it is very stable on several servers and workstations, and for quite some time now (since the kernel 2.3 series, had to watch the lists for faulty combinations though). I never used kernel 2.2 with reiserfs (3.5), but only 2.3 and 2.4 (and thus rfs 3.6). My newest workstation and notebook have one partition (/) and thus reiserfs is root and boot partition. On older ones it was necessary to have a small /boot partition because of an older version of lilo. It is no use to have reiserfs on /boot if it is small (which usually is the case), due to the journal which is 32 meg.
The bigest point so far where the fsck tools, but they seem to be quite usefull these days, and under active development.

Ookhoi

This is a reiserfs security issue, but only of theoretical nature (Even if triggered, it won't harm you). But the reason for this bug is in NFS (v2, v3, hopefully not also v4) readdir braindamage.

I think, in Reiser(FS)4, a more sophisticated (NFS-)work-around (horizontal displacement instead of vertical displacement) is planned.

I can tell you more if you want.

Xuân.

The only bad consequence possible is that you possibly cannot create a file with a given filename if someone else (remote user) could create at least 127 files with a very special filename within the same directory. Usually, /etc/shadow and all other important files either are created before any other user has access or (if they are created later) belong to directories where only root may create files in it.

:-)

If the blocks contained my old /etc/shadow I'd be a bit upset.

I trust Chris to keep it in order. I've not yet had a broken patch from them for -ac

I think we're talking about different things here. Alan, I think you are referring to the ability to get old data in files during mmap. Where the exploit roughly looks like this:

truncate(file, 0)
truncate(file, X)
char *foo = mmap(file, X)
write(file, foo, X)

This should produce all zeros, but under 2.2.x reiserfs can instead include old file data. Turns out this is because during the write, the block pointer is inserted before the newly allocated (and zero'd) buffer was set up to date. If a readpage is triggered when reiserfs_file_write calls copy_from_user, you get the old data. The fix is to mark the buffer up to date right after zeroing.

Two patches attached, one for 3.5.32 (uptodate_hole.diff.gz) and one for older reiserfs versions (uptodate_hole-old.diff.gz). Both are small, gzip'd because my mailer is dumb.

3.5.33 should come out soon with this included. 2.4.x reiserfs doesn't need this patch.

-chris