On Mon, 13 Mar 2000, Linus Torvalds wrote:
> For rather obvious PR reasons I'd love to say "yes, we have a journalling
> filesystem these days" as part of the 2.4.x release stuff, so it does fall
> under the "drivers so cool that they might make it into 2.4.x". I don't
> think I want to see the read_inode() changes, though, that's just too
> ugly. I may like the PR angle of reiserfs, but that doesn't mean that I'd
> forget about things like these completely.
>
> But it looks to me as if the read_inode thing plus a few cleanups in
> raiserfs to take into account that the VFS layer does more these days
> would certainly make it a candidate for inclusion. Maybe not 2.4.0, but
> during 2.4.x. Don't be so down on the guys, there are people who really
> like actively using raiserfs..
OK, let me summarize my position on that:
a) namespace-related methods _must_ be cleaned up. I definitely
can just rip the extra checks out of the thing, but there are questions
about correctness of said action. _If_ that was just the case of "replay
all global changes that happened during last two years" I would be
certainly PO'd but I would do it. However, some of those places do funny
things with checks for ->i_count and friends. They may be harmless
atavisms. They may be actual bugs. And they may be band-aids that cover
real problems 99% of time. I don't want any responsibility for that stuff
- analysis of reiserfs wrt races will involve going through the guts of
their code and that's about 200Kb of stuff to read. IMO that's work for
the reiserfs authors.
b) some things are obvious bugs and should be fixed both in 2.2
and 2.3 - e.g. d_move() in rename() is _wrong_ since 2.2.<early>.
c) having ~30Kb of unmaintained code in the patch is Bad
Thing(tm). What about the rest? Obviously journalling code _is_
maintained (at least I _seriously_ hope that it is). Ditto for the
allocation stuff, but here there may be need to account for big lock
changes. And I would be much happier if somebody looked through
->truncate() searching for races. Andrea?
d) could you please convert symlink.c to pagecache? BTW, that
would kill ugly REISERFS_KERNEL_MEM/REISERFS_USER_MEM stuff.
e) personally to Hans: please, _please_, lose references to Plan 9
namespaces in the documentation. Trust me, they are _NOT_ what you think
they are (at least according to what you had written). It wouldn't be
related to patch, but you are bringing the URL of that text into the tree.
I'm 100% serious - those references may be good for marketing, but they'll
make us a laughing stock for everyone who knows what Plan 9 namespaces are
about. Hint: namespaces are _not_ about "everything can be viewed as
filesystem". It's pure VFS thing and _nothing_ in your patch touches even
remotely related areas.
-
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 : Wed Mar 15 2000 - 21:00:30 EST