Re: State of NFSv4 VolatileFilehandles

[Trond Myklebust <Trond.Myklebust@netapp.com>]

On Mon, 2011-08-15 at 13:49 -0700, Malahal Naineni wrote: 
> NeilBrown [neilb@suse.de] wrote:
> > > POSIX allows the namespace to change at any time (rename() or unlink())
> > > and so you cannot rely on addressing files by pathname. That was the
> > > whole reason for introducing filehandles into NFSv2 in the first place.
> > > 
> > > Volatile filehandles were introduced in NFSv4 without any attempt to fix
> > > those shortcomings. There is no real prescription for how to recover in
> > > a situation where a rename or unlink has occurred prior to the
> > > filehandle expiring. Nor is there a reliable prescription for dealing
> > > with the case where a new file of the same name has replaced the
> > > original.
> > > Basically, the implication is that volatile filehandles are only really
> > > usable in a situation where the whole Filesystem is read-only on the
> > > server.
> > 
> > I substantially agree, though I think the implication can be refined a little.
> > 
> > I would say that the implication is that a VFH is only really usable when the
> > complete path leading to the file in question is read-only.   We don't need
> > to assume that other files in other parts of the hierarchy which have stable
> > file handles are read-only.
> 
> The spec recommends "change" attribute for validating data cache, name
> cache, etc.  Some client implementations use "change" attribute for
> validating VFH though! Can we use it for validating VFH?

The change attribute can only be used as a heuristic since it is not
guaranteed to be a value that is unique to one file.

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com