Re: reiser4: maybe just fix bugs?
From: Andrew Morton
Date: Tue Aug 01 2006 - 10:52:13 EST
On Tue, 01 Aug 2006 21:52:03 +1000
Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:
> Andrew Morton wrote:
> > On Mon, 31 Jul 2006 10:26:55 +0100
> > "Denis Vlasenko" <vda.linux@xxxxxxxxxxxxxx> wrote:
> >>The reiser4 thread seem to be longer than usual.
> > Meanwhile here's poor old me trying to find another four hours to finish
> > reviewing the thing.
> > The writeout code is ugly, although that's largely due to a mismatch between
> > what reiser4 wants to do and what the VFS/MM expects it to do. If it
> > works, we can live with it, although perhaps the VFS could be made smarter.
> > I'd say that resier4's major problem is the lack of xattrs, acls and
> > direct-io. That's likely to significantly limit its vendor uptake. (As
> > might the copyright assignment thing, but is that a kernel.org concern?)
> > The plugins appear to be wildly misnamed - they're just an internal
> > abstraction layer which permits later feature additions to be added in a
> > clean and safe manner. Certainly not worth all this fuss.
> > Could I suggest that further technical critiques of reiser4 include a
> > file-and-line reference? That should ease the load on vger.
> I haven't really reviewed it, but when I grepped through it last, I
> found a few alarming things, like use of __put_page, trying to remove
> pages from pagecache (duplicating parts of vmscan.c, plus bugs), and
> taking tree_lock.
__put_page() has gone.
A lot of the VM duplication has gone.
tree_lock is still there a bit. For two reasons:
a) A presently-unneeded duplication of the generic
b) Manipulation of the fake inode (I think).
iirc the base problem here is that for whatever reason, the usual
blockdev inode which filesystems use for metadata (ie: the pagecache
which backs sb_bread(), etc) isn't suitable. reiser4 wants to get a
hold of its address_space ops, so it needs to create its own
covers-all-the-partition, identify-mapped address_space.
> Mostly didn't look like big problems to fix, but should be fixed for
> mm/ maintainers' sanity. Maybe it's better now, though.
It's better. More reviewing help is always appreciated ;)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/