Subject: fileid in NFSv4

From: Trond Myklebust <[email-masked]>
Date: 01 Jun 2000 23:34:51 +0200

Hi,

  A question about the fileid in NFSv4: how is one supposed to
determine whether or not this value is stale when one is trying to
decide whether or not 2 files/objects are the same?

I'm thinking in particular about the statement that:
 
   "If two filehandles from the same server are equal, they MUST refer
   to the same file. If they are not equal, the client may use
   information provided by the server, in the form of file attributes,
   to determine whether they denote the same files or different
   files."

Does the above statement mean that the reuse of fileids by the server
is forbidden by the protocol?

Cheers,
  Trond

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 01 Jun 2000 19:21:04 -0500

> is forbidden by the protocol?

I am a little confused by the question, however...  I assume that you are
generally asking about filehandles.  In the case of filehandles,
they can be reused although it would be discouraged.  From the draft:

  "Since the filehandle is the client's reference to an object
   and the client may cache this reference, the server should not reuse
   a filehandle for another file system object.  If the server needs to
   reuse a filehandle value, the time elapsed before reuse SHOULD be
   large enough, measured as several hours, that it is likely the client
   no longer has a cached copy of the reused filehandle value."

So the server can reuse filehandles; I am unsure of the exact time period
for reuse but the server should try to avoid reuse until it is
no longer feasible.

The section of the I-D that you quoted is referring to the instance
that a file may have more than one hard link and therefore more than
one pathname as a reference.  This section is referring to the 
file system attribute "unique_handles" as defined as:

   unique_handles    9    boolean      READ     Are two distinct
                                                filehandles guaranteed
                                                to refer to two
                                                different file system
                                                objects?

This allows a server to return a different filehandle for the same
object when a different pathname is used to refer to that object.
With the use of this file system attribute, the client is able to
determine exactly where it stands with respect to comparing 
filehandles.  So if unique_handles == TRUE and the client receives
distinctly different filehandles, then the file objects are different.
There is a set of rules defined in "9.3.4.  Data Caching and File Identity"
in the I-D for determining equality.

As for fileid, there are no specific statements about reuse after
a particular file system object has been deleted.  As an implementation
detail, I would suggest that the server try to prolong the period
where a fileid value were reused for a particular file system.

Is there a particular problem or solution that you have in mind?

Spencer

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 2 Jun 2000 11:03:43 +0200 (CEST)

>>>>> " " == Spencer Shepler <[email-masked]> writes:

     > This allows a server to return a different filehandle for the
     > same object when a different pathname is used to refer to that
     > object.  With the use of this file system attribute, the client
     > is able to determine exactly where it stands with respect to
     > comparing filehandles.  So if unique_handles == TRUE and the
     > client receives distinctly different filehandles, then the file
     > objects are different.  There is a set of rules defined in
     > "9.3.4.  Data Caching and File Identity" in the I-D for
     > determining equality.

     > As for fileid, there are no specific statements about reuse
     > after a particular file system object has been deleted.  As an
     > implementation detail, I would suggest that the server try to
     > prolong the period where a fileid value were reused for a
     > particular file system.

     > Is there a particular problem or solution that you have in

I was thinking that if you have 2 filehandles that are different on a
server for which the unique_handles == FALSE, you might still want to
use the fileid to group the files together in order to try to ensure
local cache consistency.
This however impossible if the fileid is a volatile quantity.

So if I understand correctly, your answer seems to be that caching has
to be on a per-filehandle basis, and hence unique_handles == FALSE
means that the client cannot expect to maintain a consistent cache for
2 hard links to a single file?

Cheers,
  Trond

---

From: Uresh Vahalia <[email-masked]>
Date: Fri, 02 Jun 2000 13:09:59 -0400

> for reuse but the server should try to avoid reuse until it is

The most surefire recipe for disaster I ever have seen.