Subject: RE: recovery from NFS4ERR_FHEXPIRED

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 22 Sep 1999 07:40:25 -0700

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

If you have some unique-id (time of creation even) for the CDROM,
you can put this in each volatile file handle together with
whatever else you have in the handle (e.g. the name) Then when 
these file handles are used in a situation in which a new CDROM 
has been mounted, you return STALE if a comparison of this id 
does not match.  You just have to make sure that you do this 
before you check the rest of the handle for any of the conditions
that will cause FHEXPIRED to be generated.
  
> 
>  > > 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.
> Yes.
>  > 
>  > If that is the case, then it isn't safe in dealing with your
>  > 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.

It depends.  If you have decided that you are going to use
volatile file handles, then a partial solution is better 
than none.  On the other hand, a partial solution might cause
people to use volatile file handles when that is expedient
rather than absolutely necessary.  If we don't have a true
solution to the problem, I'd rather that people weren't
given a false sense of security, only to see some disaster
occur later.

---

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

> that will cause FHEXPIRED to be generated.

I'm sorry Dave, what am I comparing against.  The only reason that
FHEXPIRED would be returned is if I can't find the file.  The server
can only compare this unique-id after the client has performed a
new lookup.

 > given a false sense of security, only to see some disaster

I think that this should be left up to the server implimentation,
not the v4 spec.  I would point out that the spec does not say
how many bits of generation number there should be in the
filehandle, nor should it.

It may be that there should be a filesystem flag telling the client
that the server can't validate filehandles.

	Allen

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