You were using a rather unstable configuration; data striping across four
disks amounts to "please discard this data". From what you reported, it
sounded as if knfsd wasn't closing the files it had open, in which case
the right thing to do would have been to switch to a normal userspace nfsd
and see if the problem recurred.
> > > > Personally I dislike FSs which introduce their own concepts rather than
> > > > reusing or extending existing ones. Once these "kludges" are in the
> > > > kernel, they are very very hard to change or remove them. If every
> > > > journalling FS
> > > If they are the right kind, that is called evolution. And who has (who has
> > > exact idea at least of) a better one?
> > An FS is not the right place to introduce other aspects. If the VFS layer
> > needs work, work on it - but don't go bolting bits of VFS replacement code
> > into a filing system, or vice versa.
>
> Maybe then the right thing here again is not the denial, but the advise:
> Hello, guys! This and that part of how you impemented ReiserFS really
> belongs to VFS, please resrtucture it, and submit two sets of patches, one
> for VFS changes, one for the new FS. Some positive attitude needed, right?
That's exactly what was tried - but HR interpreted this as a RedHat plot
to merge his filing system into ext3, and keeps harping on about
benchmarking results between ext3 and RFS. The real issues are that RFS
should exploit a shared journalling layer, rather than supplying its own,
he's missed the deadline for including new features by quite a way. He
seems to regard kernel development as being ext3 vs RFS, and the slightest
criticism of RFS is obviously part of a RedHat plot to keep RFS out of the
kernel, while any suggestion of code sharing is a plot to merge RFS into
ext3. Noone could accuse him of being naively optimistic, anyway...
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/