In message <[EMAIL PROTECTED]>, "Pekka Enberg" writes: > Hi Hugh, > > On Sat, 13 Oct 2007, Pekka Enberg wrote: > > Doesn't msync(2) get to it via mm/page-writeback.c:write_cache_pages() > > without unionfs even? > > On 10/14/07, Hugh Dickins <[EMAIL PROTECTED]> wrote: > > I believe not. Please do double-check my assertions, I've always found > > the _writepages paths rather twisty; but my belief (supported by the > > fact that we've not hit shmem_writepage's BUG_ON(page_mapped(page)) > > in five years) is that tmpfs/shmem opts out of all of that with its > > .capabilities = BDI_CAP_NO_ACCT_DIRTY | BDI_CAP_NO_WRITEBACK, > > in shmem_backing_dev_info, which avoids all those _writepages avenues > > (e.g. through bdi_cap_writeback_dirty tests), and write_cache_pages is > > just a subfunction of the _writepages. > > Thanks for the explanation, you're obviously correct. > > However, I don't think the mapping_cap_writeback_dirty() check in > __filemap_fdatawrite_range() works as expected when tmpfs is a lower > mount for an unionfs mount. There's no BDI_CAP_NO_WRITEBACK capability > for unionfs mappings so do_fsync() will call write_cache_pages() that > unconditionally invokes shmem_writepage() via unionfs_writepage(). > Unless, of course, there's some other unionfs magic I am missing. > > Pekka
In unionfs_writepage() I tried to emulate as best possible what the lower f/s will have returned to the VFS. Since tmpfs's ->writepage can return AOP_WRITEPAGE_ACTIVATE and re-mark its page as dirty, I did the same in unionfs: mark again my page as dirty, and return AOP_WRITEPAGE_ACTIVATE. Should I be doing something different when unionfs stacks on top of tmpfs? (BTW, this is probably also relevant to ecryptfs.) Thanks, Erez. - 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/
