Subject: [nfsv4] Thanks for NFSERR_EXPIRED info

From: [email-masked]
Date: Mon, 7 Jul 2003 12:18:12 -0400 (EDT)

Hi,

> So I'm assuming from your question that your server implements the 
> premium handling.

Actually, at the moment, it would be "mid-grade 89 octane". It doesn't
throw state away until there's a conflict, but it gets rid of it all at
that point. (It doesn't return NFSERR_EXPIRED for the clientid cases,
but that's trivially fixed.) Now that I know premium is allowed, it's
awfully tempting, I just have to figure out how to fixup my restart
recovery file to handle it. (Which is an interesting little problem,
now that I'm starting to think about it.)

Anyhow, Dave, thanks for another great post. I think I know what's supposed to
happen now, rick
ps: I would be interesting in hearing what the client writers are choosing
    to do when they receive NFSERR_EXPIRED.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 7 Jul 2003 16:50:34 -0500

>     to do when they receive NFSERR_EXPIRED.

Currently, the Solaris client will treat this as a need for full
recovery (setclientid, etc.)  The client does keep track of its idea
of whether that error is "in" or "outside" of the lease period but it
doesn't go to the extremes yet to allow for servers that are premium.

At this point in protocol development, I would suggest the mainline
path for client and server and ensure that the edge cases there with
respect to recovery are handled before we wander off on the path of
premium server implementations.  I think premium will be needed for
things like network partitions that occur more frequently that we all
realize or at least occur for durations that extend beyond our initial
choices for lease periods. :-) The other thing that complicates the
premium choice is the state storage requirements that are mentioned in
the RFC.

-- 
Spencer