Messages in this thread | | | Date | Tue, 14 Mar 2000 08:11:17 -0800 (PST) | From | Chris Mason <> | Subject | Re: (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/
| |