Messages in this thread | | | Date | Mon, 2 Aug 2010 17:25:40 +1000 | From | Nick Piggin <> | Subject | Re: Formal Reiser4 inclusion and todo list? |
| |
On Sun, Aug 01, 2010 at 03:43:05PM +0200, Christian Stroetmann wrote: > Hi Glenn; > > On the 28.07.2010 21:58, I wrote: > >Aloha Glenn; > > > >At the 28.07.2010 17:21, you (doiggl@velocitynet.com.au) wrote: > >>>The following items are still unaddressed: > >>> > >>>1. running igrab() in the writepage() path is really going to hammer > >>> inode_lock. Something else will need to be done here. > >>> > >>>2. Running iput() in entd() is a bit surprising. iirc there > >>>are various > >>>ways > >>> in which this can recur into the filesystem, perform I/O, etc. I > >>>guess it > >>> works.. > >>> But again, it will hammer inode_lock.
inode_lock should be going away within 6 months or so, with the vfs-scaling developments (see linux-fsdevel).
Inode refcounting becomes very light-weight, as it should be.
> >>>3. the writeout logic in entd_flush() is interesting (as in > >>>"holy cow"). > >>> It's very central and really needs some good comments describing > >>what's > >>> going on in there - what problems are being solved, which decisions > >>were > >>> taken and why, etc. > >>> > >>>4. reiser4_wait_page_writeback() needs commenting. > >>> > >>>5. reading the comment in txnmgr.c regarding MAP_SHARED pages: a number > >>of > >>> things have changed since then. We have page-becoming-writeable > >>> notifications and probably soon we'll always take a > >>>pagefault when a > >>> MAP_SHARED page transitions from pte-clean to pte-dirty (although I > >>>wouldn't > >>> recommend that a filesystem rely upon the latter for a while yet).
It is now possible to trap all dirtying activity from all sources except get_user_pages (but filesystems tend to ignore that little problem).
| |