lkml.org 
[lkml]   [2006]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: reiser4: maybe just fix bugs?
    On 8/1/06, Andrew Morton <akpm@osdl.org> wrote:
    > On Tue, 01 Aug 2006 15:24:37 +0400
    > "Vladimir V. Saveliev" <vs@namesys.com> 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.

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

    \
     
     \ /
      Last update: 2006-08-01 21:17    [W:0.026 / U:1.532 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site