On Fri, 2008-01-04 at 12:28 -0500, Rick Macklem wrote:
> > As long as they persist while you have an open (or a delegation), it
> > shouldn't be so hard to implement, should it? If a filehandle expires,
> > then you throw away any cache associated with it, but as long as no
> > applications hold file descriptors for it, that's not a catastrophe.
> >
> > But I'm a little confused whether rfc 3530's 4.2.3 gives a way for the
> > server to express that guarantee.
>
> Agreed, but I've always assumed the server can return NFS4ERR_FHEXPIRED
> at any time. (It's listed as a error for many Ops, such as Read and Write.)
> Also, what does a client do after a server reboot. It can't use
> Open/Claim_previous for recovery.
You need to check the fh_expire_type attribute in order to figure out
what the rules are. If the bits FH4_VOLATILE_ANY and
FH4_NO_EXPIRE_WITH_OPEN are set, then the rule is that the filehandle
will not expire on OPEN as Bruce said.
On server reboot, the client gets the additional task of recovering
filehandles before it can recover opens. It can't do an OPEN by
pathname, since the server may have imposed a grace period, which will
not allow this.
Yes, this is all very silly...
> Even if there is a "don't expire while Open" guarantee, it's still a pita
> for the client to hang onto pathnames for directories and such, so that
> they can re-lookup the fh. (And if that re-lookup happens to fail or end
> up in a different place?)
Worse: if the server doesn't support fileids (which are non-mandatory
'cos NTFS & co don't have them) then you have no way to figure out if
the directory you just looked up is the same as the one you have cached.
So, while volatile filehandles may seem like a boon to server
implementations, they can still make life hell for the clients.
Trond