Subject: RE: recovery from NFS4ERR_FHEXPIRED

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 21 Sep 1999 10:56:01 -0700

> >>>Spencer Shepler said:
>  > "G. Allen Morris III" wrote:
>  >
>  > 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).
> 
> 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.

I believe it is the case that many (but not all) servers which have 
trouble mapping a unique id to a file, are capable of providing a 
unique id.

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

I'm not sure why someone removing a file you have open and creating
a new one of the same name followed by a server reboot counts as a 
bizarre scenario.  This ain't up there with Byzantine failures.

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

I think it works in the case in which the server filesystem is
readonly.  So it's not *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.

Put another way, it is forcing servers which which find
substituting one file for another (because they have the same
name) to be intolerable, not to use volatile file handles.

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

I take it the first cluster number is a disk address.

If that is the case, then it isn't safe in dealing with your
scenario since that disk address might be reused.

This is why what I proposed in a recent mail isn't safe 
either.  Comparing the fileid attribute isn't safe when
one of the files might have been deleted since fileid is
only unique within an fs at a given instant.  You need
to try to construct an identifier which is unique within
an fs for all time.  As you note above, being able to
generate such an id, is not equivalent to being able to
support persistent handles since persistent handles
also require you do be able to efficiently map
from unique id to the file object.

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

I think someone has to come up with a concrete proposal.
Volunteers?
 
I'm told that there are servers which need volatile file handles.
I'd assume that anyone interested in writing such a server would
have an interest in fixing this problem, but I haven't heard anybody
volunteer yet.  I'm not sure if it's because they don't care about
the problem, can't generate unique id's which could be used to 
solve the problem, only need to support read-only filesystems,
or what.

---

From: "G. Allen Morris III" <[email-masked]>
Date: Tue, 21 Sep 1999 12:27:03 -0700

>>>"Noveck, Dave" said:

I don't think it even works for read-only filesystems unless you
guarantee that they will never be updated.

I can see a very likely case where an iso9660 filesystem is exported,
It is CDROM so could not be more read-only.  The server is rebooted
and the CD is replaced with a new CD that has the same directory
structure, but different versions of all of the files.  I would
hope at this point that all of the filehandles would go stale
especially if it is /usr/bin/ that is being exported.

 > I take it the first cluster number is a disk address.
Yes.
 > scenario since that disk address might be reused.

But you can reduce the odds. And it seems to me any thing is better
than nothing: in the current implimentaion there is a 100% chance that
you won't catch the problem.

 > I think someone has to come up with a concrete proposal.

I'll think about it.

 > solve the problem, only need to support read-only filesystems,

   Allen

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

---

From: Gordon W Waidhofer <[email-masked]>
Date: Tue, 21 Sep 1999 14:52:27 -0700

This discussion turns on what may the client use
for file identity. There is a more important question:
What may the client do with file identity?

This gets into the whole caching question. You can
make client-side determination of file identity
as elaborate and complete as you please.
So what. Can the client-side then perform
(shadow) server-side semantics?

Whether LOOKUP("X") done 100 times
in a row produces 100 distinct file handles
or 100 identical file handles does not matter.
The server side ***MUST*** always
be in control of file op semantics, with
respect to the NFSv4 caching architecture.

So, the original question (I'm guessing based
on the Subject:) was what do you do about
NFS4ERR_FHEXPIRED. I think the
precise question is:
   "What does the client-side do with
    cached data (possibly changed)
    when it was authorized by the server
    to cache the data, but subsequently
    receives an NFS4ERR_FHEXPIRED."

Regards,
    -gww

---

From: Dickon Hood <[email-masked]>
Date: Tue, 21 Sep 1999 22:59:51 +0100

In message <[email-masked]>
          "G. Allen Morris III" <[email-masked]> wrote:

: >>>"Noveck, Dave" said:
: > > > "G. Allen Morris III" wrote:

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

: > I think it works in the case in which the server filesystem is readonly. 
: > So it's not *completely* bogus.

: I don't think it even works for read-only filesystems unless you guarantee
: that they will never be updated.

: I can see a very likely case where an iso9660 filesystem is exported, It is
: CDROM so could not be more read-only.  The server is rebooted and the CD is
: replaced with a new CD that has the same directory structure, but different
: versions of all of the files.  I would hope at this point that all of the
: filehandles would go stale especially if it is /usr/bin/ that is being
: exported.

Surely hashing the time the filesystem was mounted into the fhandle somewhere
would be good enough?  Hells, in the example above, why not the time the
server was rebooted?  Note for 'time' I mean just some number.  It could be
the statd / lockd boot count number for all I care...

I wrote a server for what is essentially a toy OS a while ago which uses an
in-RAM cache of fhandles as it has no way of referencing a file given a given
ID other than the filename.  The approach I took to solving the above problem
was to hash in either the current time when the object was first added to the
table, or just some incremented number (and on delete that value was zeroed);
I forget which.  It seemed to work.

I could be missing the point here.

-- 
Dickon Hood

Due to binaries posted to non-binary newsgroups, my .sig is 
temporarily unavailable.  Normal service will be resumed as soon as
possible.  We apologise for the inconvenience in the mean time.