Cache coherency: resync unionfs data/meta-data when lower files change
authorErez_Zadok <ezk@cs.sunysb.edu>
Mon, 11 Jun 2007 16:48:29 +0000 (12:48 -0400)
committerErez_Zadok <ezk@cs.sunysb.edu>
Mon, 23 Jul 2007 00:50:50 +0000 (20:50 -0400)
commitf232a7484603b839e5c825ddf59dbf8e9212bd4b
tree56ae112d16097feea74fe6ff35e3cabc63b4546f
parent07ffcab23e5b1318e96687d210320c42bc971e99
Cache coherency: resync unionfs data/meta-data when lower files change

Whenever we revalidate a file or dentry, we check to see if any of the lower
inodes have changed (new mtime/ctime).  If so, we revalidate the upper
unionfs objects.  This method "works" in that as long as a user process will
have caused unionfs to be called, directly or indirectly, even to just do
->d_revalidate, then we will have purged the current unionfs data and the
process will see the new data.  For example, a process that continually
re-reads the same file's data will see the NEW data as soon as the lower
file had changed, upon the next read(2) syscall.  This also works for
meta-data changes which change the ctime (chmod, chown, chgrp, etc).

However, this doesn't work when the process re-reads the file's data via
mmap and the data was already read before via mmap: once we respond to
->readpage(s), then the kernel maps the page into the process's address
space and there doesn't appear to be a way to force the kernel to invalidate
those pages/mappings, and force the process to re-issue ->readpage.  Note:
only pages that have already been readpage'ed are not updated; any other
pages which unionfs's ->readpage would be called on, WILL get the updated
data.  If there's a way to invalidate active mappings and force a
->readpage, let us know please (invalidate_inode_pages2 doesn't do the
trick).

Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
fs/unionfs/dentry.c