Re: NFS hard read-only mount option - again

[Valerie Aurora <vaurora@redhat.com>]

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@redhat.com> 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