On Wed, May 05, 2010 at 09:22:30AM +0200, Jeff Layton wrote: > On Tue, 4 May 2010 18:51:56 -0400 > Valerie Aurora <vaurora@xxxxxxxxxx> wrote: > > > > This is definitely going in the right direction, thank you. Mainly > > I'm just really ignorant of actual NFS implementation. :) > > > > Let's focus on detecting a write to a file or directory the client has > > read and still has in cache. This would be the case of an NFS dentry > > in cache on the client that is written on the server. So what is the > > actual code path if the client has an NFS dentry in cache and it is > > altered or goes away on the client? Can we hook in there and disable > > the union mount? Is this a totally dumb idea? > > > > -VAL > > Well...we typically can tell if an inode changed -- see > nfs_update_inode for most of that logic. Note that the methods we use > there are not perfect -- NFSv2/3 rely heavily on timestamps and if the > server is using a filesystem with coarse-grained timestamps (e.g. ext3) > then it's possible for things to change and the client won't notice > (whee!) > > Dentries don't really change like inodes do, but we do generally check > whether they are correct before trusting them. That's done via the > d_revalidate methods for NFS. Mostly that involves checking whether the > directory that contains the it has changed since the dentry was spawned. > > That's probably where you'll want to place your hooks, but I wonder > whether it would be better to do that at a higher level -- in the > generic VFS. Whenever a d_revalidate op returns false, then you know > that something has happened. My gut feeling is that you are right and the VFS call of the d_revalidate op is the right place to check this. My guess is that ->d_revalidate() should never fail in the lower/read-only layers of a union mount, no matter what the file system is. Can you think of a d_revalidate implementation that would fail for a reason other than a write on the server? Thanks, -VAL -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
