On Tue, 13 Jun 2000 lists@frednet.dyndns.org wrote:
> On Tue, Jun 13, 2000 at 04:54:12PM +0100, James Sutherland wrote:
> > On Tue, 13 Jun 2000, Alan Cox wrote:
> >
> > > > I've heard a couple of horror stories about RFS chewing up data.
> > > > Frankly, whether it loses data or not isn't relevant at this point.
> > >
> > > Its very relevant that a file system never loses data - it should panic
> > > the box rather than do that. That one doesnt worry me for a different
> > > reason - I know Hans cares a great deal about his fs actually working
> > > right.
> >
> > Interesting; I remember not too long ago some reference to a problem (a
> > race condition somewhere, IIRC), to which the reply was "I've run a
> > benchmark and that worked OK". It wasn't Hans himself who said that, but
> > the comment still reflected badly on the team.
> >
> > Right now, there seems to be far too much effort going into "Force the
> > code as it is into the kernel right now", and too little into "OK, it's
> > not ready to go into 2.4.0, we need to do X, Y and Z."
>
> That's really an interesting thing you've said James. I've been trying to
> pay attention to this thread quite closely, and there has maybe been (if any)
> one or two people that have stated actual problems with ReiserFS in regards
> to including it in the kernel.
There have been several specific and real problems raised.
> The bulk of this thread has been personal opinions, obscure
> references, etc. If you're this interested in proselyting about the
> evils of (heaven forbid) another filesystem, I'm sure there's an
> alt.rant.reiserfs newsgroup that would love to have this type of
> discussion.
Getting into a flamewar over a specific FS is not something I would
welcome. Where the discussion involves the Linux kernel, I am interested
in it; general rants about "is thingfs faster than otherfs" really don't
appeal. If someone comes up with a piece of code which is properly
developed and belongs in the kernel, and they are wanting to integrate it
in the correct way (inclusion in devel kernel, testing and further
development, inclusion in stable kernel), I will support it, as will
(probably) most of the people here.
> Would it be possible for actual bugs in regards to including the
> _current_ ReiserFS code be reported here and just leave personal
> beliefs out of this?
Unfortunately, it is personal beliefs which matter here. Alan will decide
what does and does not go into a test1acXX build on the basis of his
beliefs about the code in question; Linus will do the same, once he
returns. Those beliefs/decisions will be shaped, at least in part, by the
opinions of those on l-k.
In fact, if anything, it is specific RFS issues which are off-topic for
l-k. That FS is not yet a part of the kernel, so issues with it belong on
the specific mailing list for that purpose; only the kernel issue of when
and how it is integrated belongs here.
> This could actually be a very productive thread instead of just a big
> flame war if anybody would start giving real reasons. I just don't
> get the problem we're having.
The problem is that this FS should be going into a development kernel.
Unfortunately, there isn't one at the moment. The issue is being clouded
by the fact that Reiser and his company stand to benefit significantly
from inclusion in the stable kernel, so he is lobbying hard for that.
> There is quite a bit of kernel code that is even dubbed with the term
> dangerous, and I haven't seen anything that should reasonably keep it
> out of the kernel any more than, say, DevFS or NTFS write.
DevFS isn't dangerous - it isn't a data storage mechanism, so it can't
cause dataloss. NTFS write support has been in development kernels long
enough to have earned it a place in the stable kernels as well: Reiser's
code has not.
> The only negative thing I've seen is Hans getting a little
> unreasonable, but I'm starting to not blame him after seeing a lot of
> excuses for keeping good code that is being maintained and updated
> from being included because of personal belief and not because of the
> merits or demerits of the FS itself.
The code is not being excluded - noone has suggested that. What I have
been suggesting is that it should be included in a development kernel
prior to inclusion in the stable kernels. This seems perfectly reasonable,
particularly given the major upheaval adding a journalling FS entails, and
the hazard any faults in the code will represent.
> I've recently had an experience whereas before such I might have
> joined on this charade against reiserfs, but it saved the butt of a
> server we had.
I'm sure we can all point to instances where we've been able to lash up a
McGyver style system to save our posteriors - it's not a valid argument
for overriding normal procedure, though.
> A program that was running various jobs stored logs of the jobs in a
> directory that managed to accumulate (because of an extension in the
> set time to remove the old logs) 260,000 or so files in a directory.
> By the time we were able to pull it off line, We could barely access
> this directory. It took 9 hours to copy the files to a different
> location because of the vast number of them (don't we all love linked
> lists :) ).
You would probably find keeping the logs on a NetApp Filer would have
solved the problem too - shall we include one of those in the kernel? :-)
> We switched it over to ReiserFS and we haven't had trouble since then.
If you'd fixed the misconfiguration which caused the problems, you
wouldn't have had any problems under ext2 either :-)
> I know you can say things like, "Well, you shouldn't have stuck that
> many file in a single directory anyway" and, "Who else sticks that
> many files in a directory" but the fact of the matter is, ext2 is
> really starting to get a bit dated on certain concepts, and the
> quicker ReiserFS is shipped with the kernel, the sooner we'll have a
> rock solid FS to complement the state of the art in programming and
> hardware. Just my .02.
That's the problem: it's not "rock solid", it's "fast in particular
circumstances" that you are talking about. In this particular case, one FS
is faster than another - that's all. Certainly not worth bypassing the
correct development process for.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:29 EST