Hello
On Tue, 2006-08-01 at 07:33 -0700, Andrew Morton wrote:
> On Tue, 01 Aug 2006 15:24:37 +0400
> "Vladimir V. Saveliev" <[email protected]> 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().
>
no.
there is one. It is reiser4/plugin/file/file.c:writepages_unix_file().
reiser4_writepage just kicks kernel thread (entd) which works similar to
reiser4_sync_inodes() (described earlier) and waits until several pages
(including the one reiser4_writepage is called with) are written.
> I assume you considered hooking into ->set_page_dirty() to do the
> add-to-atom thing earlier on?
>
Currently, add-to-atom is not simple. It may require memory allocations
and disk i/o-s. I guess these are not supposed to be called in
->set_page_dirty(). That is why in reiser4_set_page_dirty we just mark
the page in mapping's tree and dealy adding to atoms until flush time.
> 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.
>
Do you think that if reiser4 supported xattrs - it would increase its
chances on inclusion?
PS: what exactly did you refer to when you said that writeout code is
ugly?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
