Re: State of NFSv4 VolatileFilehandles

[NeilBrown <neilb@suse.de>]

On Wed, 3 Aug 2011 05:27:26 -0700 "Myklebust, Trond"
<Trond.Myklebust@netapp.com> wrote:

> > >> - Any discussion/sugestions on the way to implement VFH?  As
> > described in RFC 3530 sections 4.2.3 and 4.2.4?
> > > I think we are avoiding volatile file handles as long as possible.
> > We don't have plans to implement them at the moment.
> > Hrm. How can we achieve the complete migration support without
> volatile
> > filehandle support?
> > What are the reasons for avoiding it? May be we can start looking into
> > this but would like to understand
> > the reasons (if any) for avoiding it.
> 
> 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.

So if the server presents us with a VFH, it seems reasonable to assume that
we can use a repeated lookup of the same name to refresh the filehandle
simply because there is no other credible way to respond to a FHEXPIRED.

So while the spec doesn't explicitly say that an expired VFH can be expected
to never be renamed, it does - as you say - strongly imply that so it seems
reasonable to proceed with implementation on that basis...

Is that convincing?

NeilBrown