Subject: [nfsv4] Volatile FH's, a client implementor's perspective

From: Rick Macklem <[email-masked]>
Date: Wed, 11 Jul 2007 11:18:00 -0400 (EDT)

I saw some recent discussion about volatile FHs and thought I'd post this:
When a client receives an NFS4ERR_FHEXPIRED, what can it do?
- The only thing I can think of is PutRootFH, Lookup,..., Lookup, GetFH
   using the path it had acquired the expired FH with. (It has to capture
   this path, but that's just a client side implementation hassle.)
   - Now, how does it know the new FH acquired above refers to the same
     file object as the one the expired FH referenced? I haven't a clue?
     I believe it can assume the Fsid and Type attributes should still be
     the same, but that isn't exactly an "iron clad" sanity check:-)

So, if servers choose to use volatile file handles, it seems they should
try very hard to make sure the same pathname never refers to a different
file.
Now, wait a minute. If the path never refers to a different file...
--> the server could use that path to create a non-volatile FH, couldn't
     it?
     - If the path is less than 128 bytes, put that in the FH, else
       compress the path
     Ok, so for long paths that won't compress down to 128 bytes, it
     doesn't quite work, but my point is that, it a server can avoid
     reuse of the path, it seems that there should be a similar mechanism
     it can use to generate a non-volatile FH?

As you might have guessed, my client doesn't handle volatile FH's, rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 11 Jul 2007 11:19:25 -0400

I would assume that you could check fsid and fileid.  It is
true that fielid is not a mandatory attribute, but most
servers do support it.

-----Original Message-----
From: Rick Macklem [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2007 11:18 AM
To: [email-masked]
Subject: [nfsv4] Volatile FH's, a client implementor's perspective

I saw some recent discussion about volatile FHs and thought I'd post
this:
When a client receives an NFS4ERR_FHEXPIRED, what can it do?
- The only thing I can think of is PutRootFH, Lookup,..., Lookup, GetFH
   using the path it had acquired the expired FH with. (It has to
capture
   this path, but that's just a client side implementation hassle.)
   - Now, how does it know the new FH acquired above refers to the same
     file object as the one the expired FH referenced? I haven't a clue?
     I believe it can assume the Fsid and Type attributes should still
be
     the same, but that isn't exactly an "iron clad" sanity check:-)

     reuse of the path, it seems that there should be a similar
mechanism

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 11 Jul 2007 12:33:11 -0500

As Dave mentions, checking the fsid and fileid are first line
methodology along with file type and other attrs like size or  
modified time.

The main thing to remember is that volatile filehandles present
a less then perfect world for the client and there are holes
on the recovery path.

Spencer

---

From: Rick Macklem <[email-masked]>
Date: Wed, 11 Jul 2007 15:31:46 -0400 (EDT)

> true that fielid is not a mandatory attribute, but most
I thought about fileid, but couldn't find anywhere in RFC3530 that said
that it won't change when an FH expires. I could see a server implementor
creating a pseudo-root fs and generating the fileids on the fly. When the
pseudo-root fs is re-created, the old FH's would expire and the new
pseudo-root fs might assign different fileids.

It might be worth clarifying that a given fileid will only represent a
given file object until that object no longer exists, so that it can be
used in the sanity check.

rick

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 11 Jul 2007 15:36:08 -0400

To me it is impied by the definition, "A number uniquely
identifying the file within the filesystem".  A number 
that changes essentially at random is not useful for
identifying a file within the filesystem.

-----Original Message-----
From: Rick Macklem [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2007 3:32 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: RE: [nfsv4] Volatile FH's, a client implementor's perspective

I thought about fileid, but couldn't find anywhere in RFC3530 that said
that it won't change when an FH expires. I could see a server
implementor
creating a pseudo-root fs and generating the fileids on the fly. When
the
pseudo-root fs is re-created, the old FH's would expire and the new
pseudo-root fs might assign different fileids.

rick

---

From: Paul Lemahieu <[email-masked]>
Date: Wed, 11 Jul 2007 14:42:45 -0700

> used in the sanity check.

Is it allowed for fsid and fileid to change when a file handle  
expires? For example, a directory has been internally moved to  
another physical file system. Access to those files now returns  
expired file handles. Objects and paths haven't changed, but file  
handles, fsids, and fileids have.

I can think of cases where the preferred resolution to an expired FH  
would be to simply ask the file server what the new file handle is,  
given the old FH. This would be particularly useful for resolving  
NFS4ERR_MOVED. The advantage is basically the one that started this  
discussion: there is no need to deal with trying to figure out if the  
object at the path is really the same object for those cases where  
the file server itself can provide the new file handle.

--Paul

Paul LeMahieu
[email-masked]

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 11 Jul 2007 20:28:24 -0400

> handles, fsids, and fileids have.

I suppose it is allowed. It would not, however be a good idea if you
want to avoid data corruption issues. It would be fairly trivial for
client1 to rename a file onto another before client2 got round to
recovering its filehandle: there is no equivalent to the grace period
when it comes to filehandle recovery.

> the file server itself can provide the new file handle.

If the server can recognise the old file handle, why would you need to
migrate it?

Trond

---

From: Paul Lemahieu <[email-masked]>
Date: Wed, 11 Jul 2007 17:44:39 -0700

> If the server can recognise the old file handle, why would you need to

Because the ability to recognise the old file handle may either be  
expensive, or a transient ability. It may be advantageous to get all  
clients on the new file handles as quickly as possible by the  
simplest mechanism possible.

--Paul