Subject: [email-masked], [email-masked]

From: Mike Eisler <[email-masked]>
Date: Fri, 2 Jun 2000 10:57:44 -0700 (PDT)

> > 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 most surefire recipe for disaster I ever have seen.

He said "avoid re-use until it is no longer feasible"

Virtually every implementation of persistent file handles avoids re-use
until no longer feasible. They include generation count in the file
handle, 32 bits long, and it is not feasable to add a bit to count to prevent
wrap around.

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.

	-mre

---

From: Uresh Vahalia <[email-masked]>
Date: Fri, 02 Jun 2000 17:02:35 -0400

> He said "avoid re-use until it is no longer feasible"

That is a very mild statement.

> handle, 32 bits long, and it is not feasable to add a bit to count to prevent

In the past, implementations have hoped that this would not cause a real problem
and, the way most people implement it, it should not.  It would require 4 billion
create/delete ops involving the same inode.

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".  If
we did reuse handles after a few hours, we would have a huge problem in real
life.  Currently, in all real environments, I bet the reuse interval is several
months (even years), with the handle being stale for the duration.  So it would
require a client staying alive, caching the file handle, but never using it, for
several months, for this to be a problem.

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)  ?

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
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?

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?

> especially since some of them have stayed up for years without a

Server reboots have nothing to do with generation count wraparounds, do they.