JGuru
Wise Old Owl
ReiserFS has serious scalability problems. David Chinner’s talk at OLS
really underscored the problem well for a single, large, high bandwidth
file system. While I realize that XFS-style scalability isn’t a real
goal for most users, ans isn’t a target workload for reiserfs, the
scalability problems are real. ReiserFS uses the BKL for synchronization
everywhere, and since it’s system-global lock, the problem doesn’t go
away when you split the file system into smaller ones. Lock contention
alone is one problem, but it’s made worse by cache bouncing between processors on larger systems.
ReiserFS has serious performance problems with extended attributes and
ACLs. (Yes, this one is my own fault, see numerous flamewars on lkml and
reiserfs-list for my opinion on this.) xattrs are backed by normal files
rooted in a hidden directory structure. This is bad for performance and
in rare cases is deadlock prone due to lock inversions between pdflush
and the xattr code. The quota code gets around this, but the fix would
result in huge amounts of wasted space with ReiserFS. With increasing
deployment of SLES as samba servers, and perhaps NFSv4 servers, the use
of extended attributes will only increase.
ReiserFS has a small and shrinking development community. Right now, the
only developers really working with ReiserFS are Chris Mason, Jan Kara
(internally), a rotating member of Hans Reiser’s team, and myself. All
of us have projects we’re very much more interested in than working with
ReiserFS. While Jan and I will be continuing to support ReiserFS for
SUSE, Hans is increasingly (hard to believe) pushing people to use
reiser4. Chris has moved on to Oracle and has expressed his opinions on
leaving ReiserFS behind.
ReiserFS v3 is a dead end. Hans has been pushing reiser4 for years now
and declared Reiser3 in maintenance mode. Any changes that aren’t bug
fixes are met with violent resistance. Reiser4 is not an incremental
update and requires a reformat, which is unreasonable for most people.
Reiser3 lacks a number of features that other file systems either have
or are adding soon, such as extents and growth beyond current limits.
Since it’s in maintenance mode, that’s unlikely to change. I view
reiser4 as an interesting research file system, but that’s about as far
as it goes. I’ve been unimpressed with its stability so far. I don’t
know how advanced the recovery tools are yet, but I suspect that the
complexity of the format and the ability to essentially define the
format on-the-fly with plugins will make a useful fsck extremely difficult.
The solution for replacing an aging file system isn’t to switch to a
brand new unproven file system, but rather a proven one with a clear
upgrade path. That file system is ext3.
Ext3’s performance in some situations may not be on par with Reiser3,
but it scales better and Andi mentioned the other day that there is
quite a bit of research going into improving the locking and general
performance of ext3 going on right now, and since reiser3 is stagnant, I
don’t doubt they’ll pass them soon.
Ext3 has a much larger development community out there. Most other
distributions use ext3 as their default file system, so bugs that don’t
end up getting reported to us and are fixed by other developers, we get
for free - most Reiser3 fixes originate from Chris or I.
Read more about it here
really underscored the problem well for a single, large, high bandwidth
file system. While I realize that XFS-style scalability isn’t a real
goal for most users, ans isn’t a target workload for reiserfs, the
scalability problems are real. ReiserFS uses the BKL for synchronization
everywhere, and since it’s system-global lock, the problem doesn’t go
away when you split the file system into smaller ones. Lock contention
alone is one problem, but it’s made worse by cache bouncing between processors on larger systems.
ReiserFS has serious performance problems with extended attributes and
ACLs. (Yes, this one is my own fault, see numerous flamewars on lkml and
reiserfs-list for my opinion on this.) xattrs are backed by normal files
rooted in a hidden directory structure. This is bad for performance and
in rare cases is deadlock prone due to lock inversions between pdflush
and the xattr code. The quota code gets around this, but the fix would
result in huge amounts of wasted space with ReiserFS. With increasing
deployment of SLES as samba servers, and perhaps NFSv4 servers, the use
of extended attributes will only increase.
ReiserFS has a small and shrinking development community. Right now, the
only developers really working with ReiserFS are Chris Mason, Jan Kara
(internally), a rotating member of Hans Reiser’s team, and myself. All
of us have projects we’re very much more interested in than working with
ReiserFS. While Jan and I will be continuing to support ReiserFS for
SUSE, Hans is increasingly (hard to believe) pushing people to use
reiser4. Chris has moved on to Oracle and has expressed his opinions on
leaving ReiserFS behind.
ReiserFS v3 is a dead end. Hans has been pushing reiser4 for years now
and declared Reiser3 in maintenance mode. Any changes that aren’t bug
fixes are met with violent resistance. Reiser4 is not an incremental
update and requires a reformat, which is unreasonable for most people.
Reiser3 lacks a number of features that other file systems either have
or are adding soon, such as extents and growth beyond current limits.
Since it’s in maintenance mode, that’s unlikely to change. I view
reiser4 as an interesting research file system, but that’s about as far
as it goes. I’ve been unimpressed with its stability so far. I don’t
know how advanced the recovery tools are yet, but I suspect that the
complexity of the format and the ability to essentially define the
format on-the-fly with plugins will make a useful fsck extremely difficult.
The solution for replacing an aging file system isn’t to switch to a
brand new unproven file system, but rather a proven one with a clear
upgrade path. That file system is ext3.
Ext3’s performance in some situations may not be on par with Reiser3,
but it scales better and Andi mentioned the other day that there is
quite a bit of research going into improving the locking and general
performance of ext3 going on right now, and since reiser3 is stagnant, I
don’t doubt they’ll pass them soon.
Ext3 has a much larger development community out there. Most other
distributions use ext3 as their default file system, so bugs that don’t
end up getting reported to us and are fixed by other developers, we get
for free - most Reiser3 fixes originate from Chris or I.
Read more about it here
