Subject: [nfsv4] Volatile file handles

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 31 Jan 2012 18:29:40 +0000

Has anyone tried implementing volatile file handles in NFSv4?

I know neither the Linux nor Solaris clients currently have it in there.

In a round about way, if no one implements part of the spec, should we consider dropping support?

---

From: Jwu-Shyan Tarng <[email-masked]>
Date: Tue, 31 Jan 2012 10:39:02 -0800

MVS NFS is supporting volatile file handles in NFSv4.

From:   "Haynes, Tom" <[email-masked]>
To:     nfsv4 <[email-masked]>
Date:   01/31/2012 10:31 AM
Subject:        [nfsv4] Volatile file handles
Sent by:        [email-masked]

In a round about way, if no one implements part of the spec, should we 
consider dropping support?
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Steven Huntington <[email-masked]>
Date: Tue, 31 Jan 2012 10:37:32 -0800

IBM zOS NFS server requires volatile filehandles.

Cheers,

Steve Huntington, IBM San Jose

Phone:       (408) 463-2716 (T/L 543-2716)
Fax:         (408) 463-4727
Office:      SVL 90-D215
Internet:    [email-masked]
Lotus Notes: Steven Huntington/San Jose/IBM@IBMUS

---

From: Matthew Treinish <[email-masked]>
Date: Tue, 31 Jan 2012 13:46:37 -0500

> In a round about way, if no one implements part of the spec, should we consider dropping support?

Currently, the z/OS server uses volatile file handles, and the AIX and z/OS
clients support volatile file handles. I have also submitted a RFC patch set to
the linux-nfs list that handles FHEXPIRED errors in the linux client.

-Matt

---

From: Bill Baker <[email-masked]>
Date: Tue, 31 Jan 2012 13:10:02 -0600

> I know neither the Linux nor Solaris clients currently have it in there.

The solaris client does support volatile file handles.

-- 
Bill Baker, Oracle Solaris NFS development

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 31 Jan 2012 19:19:10 +0000

Bad memory - I thought it was conditionally compiled in code.

Does the server support it?

---

From: "Myklebust, Trond" <[email-masked]>
Date: Tue, 31 Jan 2012 19:23:19 +0000

> consider dropping support?

Kill them... They're broken and pointless.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Bill Baker <[email-masked]>
Date: Tue, 31 Jan 2012 13:27:16 -0600

Server: no, the server has a DEBUG compile time
option to enable them, for testing purposes only.

On 01/31/12 13:19, Haynes, Tom wrote:
> On 1/31/12 1:10 PM, "Bill Baker"<[email-masked]>  wrote:
>

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 31 Jan 2012 15:08:23 -0500

Windows pnfs client tries to support them.

---

From: David Quigley <[email-masked]>
Date: Tue, 31 Jan 2012 15:31:58 -0500

> consider dropping support?

At some point there was talk about using volatile file handles to 
handle label changes in Labeled NFS. I can see if the attribute change 
notification delegate isn't supported that using volatile file handles 
would be an alternative way to implement label change notification.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Tue, 31 Jan 2012 22:15:26 +0000

> would be an alternative way to implement label change notification.

That would be a terrible design. I can think of 2 reasons off the top of
my head.

For one thing, it would preclude being able to use labelled NFS on
anything other than filesystems with a static/fixed namespace (unless
someone has a magic solution to the problem of filehandle recovery after
renames). There is admittedly a requirement that filehandles that are
FS4_VOLATILE_ANY without FH4_NOEXPIRE_WITH_OPEN are also required to
refuse RENAME and REMOVE requests on any open files and all components
of their path names. That makes them inherently incompatible with POSIX
requirements, yet still fails to deal with the problem of what to do
when you don't have a file open and, say for instance, your current
directory's filehandle expires.
It also imposes an extra burden on the server to figure out the
behaviour on RENAME of any directory that could potentially be a
component of a path to an open file.

Secondly there is the problem that changing labels while a file is open
would be a messy affair, 'cos that would require volatile filehandles
without the FH4_NOEXPIRE_WITH_OPEN property, which have terrible
properties w.r.t. OPEN. If you reading section 8.11 of RFC3530, it
states that if the client sees a new filehandle then it should assume
that it should assume that the new state is not being ORed with existing
state even if the same open owner is being used, and the filehandle does
point to the same file. There is no exception listed there for volatile
filehandles.
Even if there were such an exception, it would force the client to have
to test the filehandles in order to figure out which rule to apply
depending on whether the old filehandle is stale, expired or still valid
(read - it would require more roundtrips to the server on OPEN, and thus
would be SLOW....).

NetApp

---

From: Rick Macklem <[email-masked]>
Date: Tue, 31 Jan 2012 19:45:25 -0500 (EST)

> The solaris client does support volatile file handles.
Can I assume by support you mean that, when the client receives a
NFS4ERR_FHEXPIRED it does something like:
PUTROOTFH, LOOKUP,...,LOOKUP, GETFH
(for all the name components that were used to acquire the original FH)
and then it "hopes" that the new FH actually refers to the same file
object and not just a different one under the same name?

I can imagine some pretty interesting behaviour when the file object
has been replaced by one with the same name.

The FreeBSD server never generates them and the FreeBSD client has no
idea what to do with NFS4ERR_FHEXPIRED (ie. it's a fatal error).

rick, who is basically in Trond's camp on this one.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 1 Feb 2012 03:04:36 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rick Macklem
> Sent: Tuesday, January 31, 2012 4:45 PM
> To: Bill Baker
> Cc: [email-masked]
> Subject: Re: [nfsv4] Volatile file handles
> 
> Bill Baker wrote:
> I can imagine some pretty interesting behaviour when the file object has
> been replaced by one with the same name.
> 
> The FreeBSD server never generates them and the FreeBSD client has no idea
> what to do with NFS4ERR_FHEXPIRED (ie. it's a fatal error).

Yes, the race conditions that exists with volatile file handles was understood
at the time the functionality was written into the specification.

The intent was that volatile file handles was not meant to be a general
solution.  It was meant to provide method for a server to create the intermedidate
components of the pseudo namespace (the "top" portions of such) in a way
that did not require full persistence with respect to fileids/persistent file handles.
The second use case was for those servers that did not have a file system that
provided unique/persistent identifiers for the file system objects.  In NFSv3, they
misrepresented the persistent file handles and in many cases have the same
race condition that you speak of above.  Again, the intent was to provide
a method for the client to know about this and make a choice in that it could
outright fail (as you and Trond have chosen for your implementations), it could
recover and outright ignore the issue, or it could recover and make an attempt
to "match" the previous file if it were actively open.

For use in the pseudo namespace, I think the solution is very helpful.  Beyond that,
I don't have a strong opinion because none of it is perfect...

Spencer