Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Matthias Andree <matthias.andree@gmx.de>]

On Sun, 23 Jul 2006, Hans Reiser wrote:

> I want reiserfs to be the filesystem that professional system
> administrators view as the one with both the fastest technological pace,
> and the most conservative release management.

Well, I, with the administrator hat on, phased out all reiserfs file
systems and replaced them by ext3. This got me rid of silent
corruptions, immature reiserfsprogs and hash collision chain limits.

> I apologize to users  that the technology required a 5 year gap between
> releases.   It just did, an outsider may not realize how deep the
> changes we made were.  Things like per node locking based on a whole new
> approach to tree locking that goes bottom up instead of the usual top
> down are big tasks.    Dancing trees are a big change, getting rid of
> blobs is a big change, wandering logs.....  We did a lot of things like
> that, and got very fortunate with them.  If we had tried to add such
> changes to V3, the code would have been unstable the whole 5 years, and
> would not have come out right.

And that is something that an administrator does not care the least
about. It must simply work, and the tools must simply work. Once I hit
issues like "xfs_check believes / were mounted R/W (not ignoring rootfs)
and refuses the R/O check", "reiserfsck can't fix a R/O file system"
(I believed this one got fixed before 3.6.19) or particularly silent
corruptions that show up later in a routine fsck --check after a kernel
update, the filesystem and its tools appear in a bad light. I've never
had such troubles with ext2fs or ext3fs or FreeBSD's or Solaris's ufs.

I'm not sure what patches Chris added to SUSE's reiserfs, nor do I care
any more. The father declared his child unsupported, and that's the end
of the story for me. There's nothing wrong about focusing on newer code,
but the old code needs to be cared for, too, to fix remaining issues
such as the "can only have N files with the same hash value". (I am well
aware this is exploiting worst-case behavior in a malicious sense but I
simply cannot risk such nonsense on a 270 GB RAID5 if users have shared
work directories.)

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/