Messages in this thread | | | Date | Tue, 1 Aug 2006 07:54:22 -0700 | From | Andrew Morton <> | Subject | Re: reiser4: maybe just fix bugs? |
| |
On Tue, 01 Aug 2006 21:52:03 +1000 Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> Andrew Morton wrote: > > On Mon, 31 Jul 2006 10:26:55 +0100 > > "Denis Vlasenko" <vda.linux@googlemail.com> 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 __set_page_dirty_nobuffers() and
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |