lkml.org 
[lkml]   [2000]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (reiserfs) Re: patch: reiserfs for 2.3.49


On Tue, 14 Mar 2000, Alexander Viro wrote:

[snip]

> 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>.

We agree, these fixes have already started. We'll send them to you as
they stabilize. I would much rather have your help getting rid of
read_inode2 than cleaning up our other messes ;-)

> c) having ~30Kb of unmaintained code in the patch is Bad
> Thing(tm).

The code is maintained. All of it. Clearly we dropped the ball on
keeping up with VFS changes, it won't happen again.

> 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?

Andrea did offer to help us out, I think it would be best if he did it
after the first batch of VFS related changes is done. But Andrea, if you
have a free moment, looking through truncate is a great place to start.

> d) could you please convert symlink.c to pagecache? BTW, that
> would kill ugly REISERFS_KERNEL_MEM/REISERFS_USER_MEM stuff.

I'll look into this. I'm not sure it is possible to do it right until we
convert all metadata into the page cache, which we are looking into as
well.

thanks again,
Chris


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site