Subject: recovery from NFS4ERR_FHEXPIRED

From: "G. Allen Morris III" <[email-masked]>
Date: Mon, 20 Sep 1999 03:08:29 -0700

3.3 Client Recovery from File Handle

  I am worried that LOOKUP is not up to the job of recovering
from an NFS4ERR_FHEXPIRED in some cases.

For example how can the following be handled?

  Client has filehandle for file A

  On the server file A is deleted and A' is created.

  if the client where to attempt to access file A a this point
  the server would return ESTALE.  But if the server where to
  loose the cache (because of a reboot or some such) it would
  return FHEXPIRE instead.

  The client would then lookup A and the server would set the cfh to A'.

  It seem that a validate filehandle Operation is needed.

  This might also help in migration.  A checksum for files could be stored
  in the filehandle (this would not be very expensive on a read only
  filesystem).  The server would then be able to verify that it had the
  same version of the file as the previous server.  And if not could 
  return ESTALE.

    So if you get an FHEXPIRED while reading file /A/B/C you would

    PUTROOT
	LOOKUP "A" "B" "C"
    UPDATEFH (old filehandle for C)

	Where UPDATEFH is the same at GETFH except that it takes a filehandle
	for an ARGUMENT and does not have FHEXPIRED as one of its ERRORS.

    Allen

----------------------

--
Allen Morris <[email-masked]>

---

From: Mike Eisler <[email-masked]>
Date: Mon, 20 Sep 1999 06:59:15 -0700 (PDT)

>   It seem that a validate filehandle Operation is needed.

What would 'validate filehandle' do?
>   same version of the file as the previous server.  And if not could 

The server is free to stick a checksum into the file handle without
adding a new oepration to the protocol.

	-mre

---

From: "G. Allen Morris III" <[email-masked]>
Date: Mon, 20 Sep 1999 11:09:26 -0700

>>>Mike Eisler said:

There is currently (as far as I know), no way for a client to compare
two filehandles and know if they point to the same file (bag-o-bits).

Can you tell me how I can test if two filehandles point to the same file?
Note that one of the filehandles returns FHEXPIRED for all operations.

  Allen

---------------------------------
       G. Allen Morris III

---

From: Mike Eisler <[email-masked]>
Date: Mon, 20 Sep 1999 11:20:13 -0700 (PDT)

> two filehandles and know if they point to the same file (bag-o-bits).

Correct, although if unqiue_handles attribute is TRUE, then
if the file hanbxles are diffetent they point ot to different files.

> Can you tell me how I can test if two filehandles point to the same file?

If unique_handles is FALSE you cannot. But what does this have to do with
your proposed 'validate filehandle' operation? I still don't understand
what the the proposed operation would do.

	-mre

---

From: "G. Allen Morris III" <[email-masked]>
Date: Mon, 20 Sep 1999 11:31:24 -0700

> what the the proposed operation would do.

All it is is a compare filehandle operation.

It is VERY likely that this can be handled without adding a new operation.

  Allen

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 20 Sep 1999 19:34:02 -0500

> It is VERY likely that this can be handled without adding a new operation.

When we had the volatile file handle discussion, it was suggested
that the client could check the 'change' and 'object_size' attributes
upon recovery from receipt of NFS4ERR_FHEXPIRED.  Obviously in the case
that the client was able to find the filename upon recovery.

Spencer

---

From: "G. Allen Morris III" <[email-masked]>
Date: Mon, 20 Sep 1999 22:10:58 -0700

>>>Spencer Shepler said:

This would imply that the client must cache the change and size
attributes for each file and make sure that they are always up-
to-date.

I guess the client to could read each file it opens and run that through
MD5 and then when it gets an NFS4ERR_FHEXPIRED it could read the new
file and compare the digests :-]

I am just not sure why there is no general way to compare to filehandles.
That is point to the same file with the same export permisions.  And do
this without forcing the use of `unique_handles'.

A meathod to do this that I have proposed before is to break the 
filehandle into two parts: a static part and a volatile part.
If two file handles have the same static parts they then point
to the same file.  To do this takes one byte.

No one has told me how I can impliment volatile filehandles without
using the unique_handles flag.  I don't think there is one.

    Allen

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 21 Sep 1999 00:19:41 -0500

> using the unique_handles flag.  I don't think there is one.

The unique_handles attribute is used to tell the client if it can
compare two filehandles for two file objects and determine if
they are the same file object.  This is meant to be used at the
same point in time for two distinct paths.  For example, filehandles
for /a/b/c and /a/b/d can be compared to determine if these paths
are hard links to the same file object.

The question of comparing two filehandles for the same path in the
case of volatile filehandles is not addressed by the use of 
the unique_handles attribute.

Volatile filehandles are in place for those servers who can not
provide a unique identifier for a file; therefore, they can not
implement the static/volatile suggestion you make (for example a
FAT filesystem).

It is preferable that a file server provide persistent filehandles
because it removes bizarre scenarios as you point out but it is
not a requirement because we know some fileservers can not provide
persistent filehandles.

Spencer

---

From: "G. Allen Morris III" <[email-masked]>
Date: Mon, 20 Sep 1999 23:18:19 -0700

> implement the static/volatile suggestion you make (for example a

Linux can provide a unique identifier for a file, it is just that
it may not be able to find the file using that identifier.

 > not a requirement because we know some fileservers can not provide

And the current volatile filehandle only pretends to address this
problem.  It is completely bogus!

Would you even think of having filehandles that did not have
generation numbers?  That is what you are forcing any server
that uses volatile filehandles to do.

All I have to think of is what I would put in a filehandle that
was not limited to 128 bytes.  If I was going to do this for the
MSDOS filesystem I would put in the path and the first cluster
number.  I would not just put in the the path, but that is all
that the current volatile filehandle scheme gives to the server.
So this scheme is inadequate.

Shall we decide how to fix it, or just leave it broken?

  Allen