Re: [PATCH/RFC 0/7] Volatile Filehandle Client-side Support

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

On Sat, 12 Nov 2011 09:49:53 -0500 Christoph Hellwig <hch@infradead.org>
wrote:

> On Fri, Nov 11, 2011 at 07:13:29PM -0500, Trond Myklebust wrote:
> > On Fri, 2011-11-11 at 18:04 -0500, Matthew Treinish wrote: 
> > > This patch series implements client side support for volatile file handle
> > > recovery (RFC 3530 section 4.2 and 4.3) with walk back using the dcache. To
> > > test the client you either need a server that supports volatile file handles or 
> > > you can hard code the server to output NFS4ERR_FHEXPIRED instead of
> > > NFSERR_STALE. (See the last patch in the series)
> > 
> > WHY do we want to support this kind of "feature"? As you said, the RFC
> > doesn't actually help in figuring out how this crap is supposed to work
> > in practice, so why do we even consider starting to give a damn?
> 
> *nod*. Pretending we handle it seems fairly dangerous.  I'd much prefer
> outright rejecting it.

Hence the suggested mount option.

A server might not be able to provide stable file handles, but can ensure
that files don't get renamed - for these filesystems, the name is a
reliable stable handle for the file (it just doesn't fit in the NFSv4 file
handle structure).

So if you know the filesystem will only return FHEXPIRED for filehandles
belonging to files that cannot be renamed, then it is perfectly reasonable to
repeat the name lookup to re-access the file after the server forgets about
an old filehandle.  The mount option is how you communicate this knowledge,
because the RFC doesn't provide a way to communicate it.

NeilBrown



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]