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@xxxxxxxxxxxxxxxxxx) 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). -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
