Subject: RE: fileid in NFSv4

From: mre <[email-masked]>
Date: Fri, 2 Jun 2000 14:47:16 -0700 (PDT)

> Date: Fri, 02 Jun 2000 17:02:35 -0400
> From: "Uresh Vahalia" <[email-masked]>
> Subject: Re: [email-masked], [email-masked]
> To: "Mike Eisler" <[email-masked]>
> Cc: [email-masked]

> > > The most surefire recipe for disaster I ever have seen.
> >
> > He said "avoid re-use until it is no longer feasible"
> 
> That is a very mild statement.

I find it to be a concise statement that provides a satisfactory litmus
test.

> My objection is to putting such wishy-washy language in the spec.  Especially
> when we relax the limits totally and talk of not reusing for "several hours".

After realizing that Solaris cachefs code caches file handles on disk,
I quite agree with you that "hours" is not sufficient. It would be best to
not mention a time frame, or at least point out that scenarios where
clients cache file handles for long periods of time.

> Another important point, perhaps the one that sparked this thread, is getting
> overlooked in the discussion.  We all agree that
>     (handle1 == handle2) ==> (file1 == file2)
> Does (handle1 != handle2) ==> (file1 != file2)  ?

This was brought a year or two ago, and beaten to death.

> The responses from Spencer and Dave seem to indicate that this is not true, 
that
> it is OK for the server to return two different handles for the same file, and

There are valid security reasons why the file handles are different.

No one has provided a viable alternative that meets the security
requirements. Hard links suck. AUTH_SYS sucks. Oh well.

> that the client can use other file attributes to check this.  If so, is there 
a
> specific set of attributes that must be checked to determine that the two
> represent the same file?  Traditionally, this has been the <fileid, 
generation>
> pair.  Does the draft specify this?

Covered in section 9.3.4 I believe. 

> Finally, in nfsv2 and nfsv3, the only time one could have multiple different
> handles for the same file (at least for Unix-based servers) was if the client
> came through different mount points.  I know nfsv4 moves away from the notion 
of
> mounts.  Does this mean that the servers will return different handles for the
> same file more capriciously?

I don't think you can draw any meaning at all. In NFS[v23] file handles
were different because they came in through different export points,
which sometimes map one to one to the server's mount points of local
file systems.  NFSv4 doesn't mandate that servers have a single export
or mount point.  So it is safe to conclude that NFsv4 servers with
multiple export/mount points will continue to return different export
points.

> > Perfect semantics are impossible once you throw in a network that is
> > deliberately designed to be less than perfect.
> >
> > I'm confident there are servers that have re-used file handles,
> > especially since some of them have stayed up for years without a
> > reboot.
> 
> Server reboots have nothing to do with generation count wraparounds, do they.

Oops yes of course. I'm confident there are servers that have re-used file 
handles, since some of them have been in service for years.

	-Mike Eisler

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 05 Jun 2000 00:23:35 -0500

> clients cache file handles for long periods of time.

Okay. I will remove the time frame statement and add the following to 
this paragraph:

"Note that a client may cache a filehandle for a very long time.  For
example, a client may cache NFS data to local storage as a method to
expand its effective cache size and as a means to survive client
restarts.  Therefore, the lifetime of a cached filehandle will be 
greatly extended."

Spencer