I recently switched all five of my home PCs from ReiserFS to ext4. The oldest machines had been using ReiserFS 3.6 since Slackware 10.0 came out in 2004. For consistency, I continued to use ReiserFS on newer machines and newer Slackware releases. Today, all of my machines run a snapshot of Slackware64 or 32-bit Slackware from last year, after 13.37, with a custom 2.6.39.4 kernel.

I had noted two problems with ReiserFS:

1. When writing large amounts of data (100MB-2GB), all shell windows on the computer would freeze for several seconds to as long as ten or twenty seconds. This was very annoying. I'm guessing that there is some fairness problem or long serial path in ReiserFS. Switching to ext4 completely eliminated the pauses. Subjectively, ext4 seems faster than ReiserFS.

1. On one machine with two hard disks and two optical disks, I would occasionally experience data corruption when all four drives were in use simultaneously. The data corruption would happen about once every 1-2 months... it showed up as a failure to open a subdirectory during a recursive traversal. I'm guessing that this may be due to a lock or race problem in ReiserFS. I haven't run ext4 long enough to confirm that this problem has truly gone away, but I suspect that it has.

So... if you are still using ReiserFS, now is a good time to switch! I wanted to switch filesystems in preparation for upgrading to Slackware 14.0.
Ed

I found this on Google.

Also, this.

ReiserFS isn't developed anymore (AFAIK). I think Reiser4 is more upstream.

Alex Brinister

I got the impression ReiserFS was pretty much over when Hans Reiser went to jail?
Seems the problems are built in:
http://en.wikipedia.org/wiki/ReiserFS#Criticism

Alex - the pauses that I was experiencing were not hangs or crashes. The computer always eventually responded. The pauses were very reproducible.

273 - yes. ReiserFS is a bad choice today, but it was the preferred filesystem on Slackware for years. There are likely a lot of people who have kept their data on ReiserFS through multiple Slackware upgrades.
Ed

Oh I see. That's interesting.

It used to be the default on openSuse until 2006.

Alex Brinister

I quit using Reiser many years ago after it ate itself a few times. Never had a FS do that ever. Put XFS on the same drive no problems.

Also I observed booting times on ResierFS going up by minutes the older the install was over time. It was a shitty FS, FAT under Windows 9x gave me less problems. It got popular by the fact it was the first journaling fs for Linux.

Pixxt - the data corruption bug that I noted above was the only functional problem I encountered. Fortunately, I didn't lose data. I'm assuming this bug is in ReiserFS, but I'm not completely sure.

I think ReiserFS was a great filesystem at the time it was introduced, but its development stopped when Hans Reiser went to jail. ReiserFS didn't keep up with the locking changes in the kernel (the pauses started appearing around the same time the kernel locking underwent an overhaul), and it also didn't keep up with quad-core CPUs. ReiserFS may still be part of the kernel, but it doesn't perform well (or possibly even work correctly) today.
Ed

ReiserFS was a great File system for it's time. Between all the problems EXT3 was trying to solve for EXT2 and data loss problems, ReiserFS was the most advanced file system we had at the time in terms of data integrity checking, loss prevention, corruption prevention, and performance. On old Pentium 3 and Athlon single core CPUs it scaled well and had great performance where other file systems still had issues.

When EXT4 solved the problems of EXT3 and EXT2 it also deprecated ReiserFS's usefulness because EXT4 performed not only the same functions but had better performance and CPU scaling abilities for larger hard drives. It also was supported by all major bootloaders at the time including LILO.

However, EXT4's usefulness is now being limited by BtrFS's capabilities which are attempting to match and surpass the abilities of Sun's ZFS obfuscating EXT2/3/4 down to being useful only as boot partition styles. The only problem is BtrFS can not be natively booted by certain bootloaders like LILO, yet.

For a modern system, I'd advise against using ReiserFS unless no other file systems like EXT4, BtrFS, and such are natively supported. It's not able to scale well with modern CPUs and doesn't have good performance against modern disk arrays.

Reiser4 will probably never be completed or added to the kernel outside or 3rd party patches and development for both ReiserFS (v3) and Reiser4 will probably never be picked up again unless it's to remove ReiserFS support entirely or move it over to FUSE and begin deprecation processes to eventually remove it entirely.

Hello EdGr,

I'm a long time ReiserFS user (since 2001) and I've been using it almost exclusively all of these years on all my servers (between my home server, my company's servers, and even our customers' servers, we have some tens of terabytes of data on it). During all that time, ReiserFS has proved to be the most robust filesystem we have ever used (and we used quite a lot of them): in situations where Ext3 would lose data and crash, ReiserFS simply kept going, including a case of silent disk corruption due to hardware issues on 2 disks of a 3-disk RAID5 array (the only data we lost was in the blocks corrupted by the bad disks, and this data was promptly restored from the backup; the rest of the filesystem continued in use and working while we diagnosed the situation and eventually replaced those disks, which we did without even having to stop the machine: we simply replaced a disk at a time and then rebuilt the RAID).

It's a badly guarded secret (for those that follow the reiserfs-devel mailing list) that maintenance of the ReiserFSv3 code in the kernel started being not that good at some point after kernel 2.6.32 was released; I have personally had lots of issues (like spontaneously disappearing and reappearing files) with kernel 2.6.37, so I think kernel 2.6.32.x is really the last one where ReiserFSv3 can be used reliably (I use kernel 2.6.27.x in production here, and kernel 2.6.32 in development/test machines).

Not really true: there are a handful of developers still working on maintaining at least ReiserFSv3 (can't say anything about V4 as I don't use it and so do not follow its development), not only on the reiserfs-devel mailing list, but also from SUSE (most notably Jan Kara and Jeff Mahoney) and a few others. Patches to fix problems on ReiserFS with the newest kernels show up at least once or twice a month, see for example these two:

http://www.spinics.net/lists/reiserf.../msg03226.html
http://www.spinics.net/lists/linux-f.../msg57249.html

What is really missing is the momentum that Namesys (Hans Reiser's company) and its employees gave to the ReiserFS development and maintenance, and here I agree that the situation is not only bad but still deteriorating.

It mostly works as long as you keep your kernel to the latest releases of 2.6.32.x, or even better, 2.6.27.x; but I guess you were referring to newer kernels, which I feel no urge to upgrade to (I doubt very much that Reiserfs is the only part of these kernels with issues, due IMNSHO to the frantic "leave no prisoners" attitude the kernel developers have been taking lately).

Cheers,
--
Durval Menezes.

I remember a filesystem comparison table from a few years ago, where one of ReiserFS' few drawbacks was "Murders your wife".

http://farm4.static.flickr.com/3281/...4e7d8911_o.jpg

Luckily, that was removed from Wikipedia quickly enough upon being reported.

Hi Durval,

That sounds similar to the data corruption problem that I was experiencing: recently-created files would fail to show up in the directory (at least momentarily). The bug would occur only if there was simultaneous activity on the optical and hard disks. I didn't report the problem because it is nearly impossible to reproduce.

My experience has also been that ReiserFS was very reliable prior to 2010.

This morning, I noticed that the occasional video playback stutters on my oldest PC (750MHz Pentium III) went away when I switched from ReiserFS to ext4. Up until now, I had thought that old computer was too slow for video.
Ed

One way to reliably reproduce this issue in a few hours is to run the memtest.sh script by dledford: http://people.redhat.com/dledford/memtest.shtml

This script was originally intended to expose hard-to-reproduce memory (hardware) errors, but I've found that the stress that it puts into a filesystem is also a good test of its performance and reliability under heavy load.

Same thing here.

I have some PIII machines still in production (industrial server hardware in special applications) and they are all running kernel 2.6.27 with ReiserFS with no issues at all. But then, they do not play any video ;-)

Cheers,
--
Durval.

Interesting.

That script is doing the same thing that my script was doing whenever I saw failures: unpacking a tar file and recursively diff'ing the directories. I ran several instances of the script.

I'm not going to debug this now.
Thanks,
Ed

Hi EdGR,

Ditto ;-) I expect to be in your situation when ZFSOnLinux stabilizes enough (and has good enough performance) for me to migrate to it; with any luck I will be able to bypass ext4 completely and (I hope) migrate to BtrFS if and when it achieves a reasonable level of maturity.

Even for people like me who are still using it, ReiserFS is really in a "end-of-life" situation... I've determined that it works very well up to and including 2.6.32, and that's where I will stay until the time I can reliably migrate to something equivalent in terms of speed and reliability... and there's no rush as 2.6.32 is the official RHEL6 kernel and so will be supported by RH -- including backports/cherry-picking from newer kernels to enable it to continue to run on newer hardware) at least until 2016.

Cheers,
--
Durval Menezes.