On Fri, Jan 04, 2008 at 12:28:26PM -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.
I was hoping that FH4_VOL_NOEXPIRE_WITH_OPEN might also cover opens over server reboot, but that's a question for the ietf list. And perhaps the requirement to keep that filehandle->inode mapping in persistant storage would negate the advantage to the server of volatile filehandles. > 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?) I'm confused--can't you just throw away your lookup/readdir cache for that directory and not use it again until an application actually does a new lookup? Oh, but I guess the client can hold references to the directory itself in the form of filehandles or current working directories. So I guess you'd need some kind of open/close (or get/put) operations for directories as well to get agreed-on lifetimes for directory filehandles. Does it still seem worth it after all that? --b. - To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
