Subject: RE: recovery from NFS4ERR_FHEXPIRED

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 27 Sep 1999 07:14:47 -0700

> This is a good answer. It follows the client-side
> implementations need to be prepared for NFS4ERR_GRACE
> from all ops, not just OPEN or LOCK.

I'm not sure about *all* ops.  Should it be valid
to return NFS4ERR_GRACE for PUTFH or SETCLIENTID,
for example?  The list should be definitely expanded.
It's not clear whether we just have a small set
for which NFS4ERR_GRACE is allowed (OPEN, LOCK,
REMOVE, RENAME) or allow it for everything except
some other set of exceptions.

> 
> Is it safe to say the pathname is the only
> possible recovery for volatile file handles?
> Only repeated LOOKUPs and OPENs can recover
> expired handles? I believe so. Comments?
> 
> The NFSv4 spec should at least *RECOMMEND*
> that servers which return volatile file handles
> defend the file name space and also use
> the trans-reboot grace period as Carl
> described. The spec should also *REQUIRE*
> client implementations to handle NFS4ERR_GRACE
> for all operations.

The client should certainly be required to
handle anything that we recommend that servers
do. 

> A set of *RECOMMENDED*
> heuristics for the client-side to defend
> file content would also be a good topic
> for the spec, but since file identity is
> problematic, such heuristics should not be
> required of either the client nor server.

If a server is going to take an open file and
all of a sudden connect it to a different object
then I'm not sure what heuristics a client could
use to defend it's files other than to not use
such a server.

> 
> The whole mechanism begs the question of a lost
> CLOSE. There are similar issues for client-side
> caching, and I would urge that the same
> mechanism be used in this case.

I'm confused.  What mechanism begs what question
regarding a lost CLOSE? What are the similar
issues for client-side caching and what mechanism
needs to be used in that case?

> 
> OBTW, SMB ain't got a solution for the
> client/client trans-reboot race condition.
> Chalk one up for NFSv4. I love it when
> that happens. Nice going, Carl.
>

---

From: Gordon Waidhofer <[email-masked]>
Date: Mon, 27 Sep 1999 10:09:01 -0700

> use to defend it's files other than to not use

It shouldn't be sudden. The risk exists for all
file models which lack a file identity (like
ino+gen) other than pathname.

> needs to be used in that case?

For caching, a lost CLOSE means that the current
copy may still be on the client. How long and hard
does the server try to recover file content from
the client before unilateraly revoking the
caching "delegation"?

For volatile file handles, a whole lot of names
in a path are essentially locked pending
conclusion of the volatile file handle.
If no CLOSE, then how is the volatile file
handle concluded? How are the locks on the
pathname released?

-- 
==================================================================
  Gordon W Waidhofer                    Traakan Software, Inc.
  [email-masked]                       111 Main St., Suite #5
  650-947-1583  Direct                  Los Altos, CA  94042
  650-947-1580  Main                    http://www.traakan.com
  650-947-1588  Fax