[lkml]   [2006]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: reiser4: maybe just fix bugs?
On 8/1/06, Andrew Morton <> wrote:
> On Tue, 01 Aug 2006 15:24:37 +0400
> "Vladimir V. Saveliev" <> wrote:
> > > >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.
> >
> > Yes. reiser4 writeouts atoms. Most of pages get into atoms via
> > sys_write. But pages dirtied via shared mapping do not. They get into
> > atoms in reiser4's writepages address space operation.
> It think you mean ->writepage - reiser4 desn't implement ->writepages().
> I assume you considered hooking into ->set_page_dirty() to do the
> add-to-atom thing earlier on?
> We'll merge mm-tracking-shared-dirty-pages.patch into 2.6.19-rc1, which
> would make that approach considerably more successful, I expect.
> ->set_page_dirty() is a bit awkward because it can be called under
> spinlock.
> Maybe comething could also be gained from the new
> vm_operations_struct.page_mkwrite(), although that's less obvious...
> > That is why
> > reiser4_sync_inodes has two steps: on first one it calls
> > generic_sync_sb_inodes to call writepages for dirty inodes to capture
> > pages dirtied via shared mapping into atoms. Second step flushes atoms.
> >
> > > >
> > > I agree --- both with it being ugly, and that being part of why.
> > >
> > > > If it
> > > >works, we can live with it, although perhaps the VFS could be made smarter.
> > > >
> > > >
> > > I would be curious regarding any ideas on that. Next time I read
> > > through that code, I will keep in mind that you are open to making VFS
> > > changes if it improves things, and I will try to get clever somehow and
> > > send it by you. Our squalloc code though is I must say the most
> > > complicated and ugliest piece of code I ever worked on for which every
> > > cumulative ugliness had a substantive performance advantage requiring us
> > > to keep it. If you spare yourself from reading that, it is
> > > understandable to do so.
> > >
> > > >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.
> >
> > xattrs is really a problem.
> That's not good. The ability to properly support SELinux is likely to be
> important.

i disagreee that it will be difficult. unfortunately, the patch that
I am working on right now, which fixes the various reiser4 specific
functions to avoid using VFS data structures unless needed, is a
prerequisite to enabling xattrs. creating it is a time of tedium for
me, and it will cause a bit of internal churn (1000 lines and
counting). it's all in the fs/reiser4 directory though, and it should
cause minimal disruption, as far as runtime bugs introduced.

once that's taken care of, i will be delighted to enable xattr support
in a way that will make selinux and beagle and such run as expected,
and will have the added advantage of some major scalability
improvements for certain lookup and update operations.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-08-01 21:17    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean