[nfsv4] more re: NFS4ERR_EXPIRED

rick@snowhite.cis.uoguelph.ca

From: rick@snowhite.cis.uoguelph.ca
Date: Thu, 6 Jan 2005 16:02:56 -0500 (EST)
Message-Id: <200501062102.QAA24523@snowhite.cis.uoguelph.ca>
Subject: [nfsv4] more re: NFS4ERR_EXPIRED

> rick@snowhite.cis.uoguelph.ca wrote:
> > > I also allow the SetClientID/confirm to lift the embargo, although I am
> > > still on the fence as to whether or not that should be the case.
> 
> Spencer Shepler wrote:
> > The server has to return NFS4ERR_EXPIRED to old state from the client
> > regardless of how long the client keeps sending it (unless the server
> > eventually reboots).  Even if the client does a
> > SETCLIENTID/SETCLIENTID_CONFIRM and is confused enough to send old
> > state requests, those old state requests still have to receive
> > NFS4ERR_EXPIRED.
> 
> Why?

Hopefully Spencer will chime in and correct this, but here's my current
understanding of it.

When a client does a SETCLIENTID/SETCLIENTID_CONFIRM, it does not necessarily
assume that it has to re-establish state. (The SETCLIENTID/SETCLIENTID_CONFIRM
could just be changing the callback pathway, for example?) As such, the
client will not assume that unexpired state is no longer valid.
--> The server must still return NFS4ERR_EXPIRED for the revoked state.
    Now, why isn't returning NFS4ERR_EXPIRED to the client once sufficient?
    I think the problem here is that the only guarantee that the client has
    received an NFS4ERR_EXPIRED would be the next state op in sequence by
    seqid#. Admittedly, NFS4ERR_EXPIRED isn't one of the errors that doesn't
    increment the seqid, but I suspect that clients aren't going to bother to
    do any more Ops on a Stateid once it has received NFS4ERR_EXPIRED. As such,
    the server won't receive the next Op in sequence, in practice.
    --> The server has to be prepared to keep returning NFS4ERR_EXPIRED until
        it reboots.

Related to this is that, if the client doesn't try and use the Stateid between
when the server revokes it and when the server reboots, this results in an
edge condition essentially the same as when the client is partitioned from
the server until the Reclaim after reboot.

In other words, if the client doesn't receive NFS4ERR_EXPIRED for the Stateid
before the server reboots, it will try and Reclaim the state.
--> The server must know not to allow this state to be reclaimed during Grace.
    --> The server will need a more involved stable storage restart mechanism
        than that described in the RFC.

As such, my current server code only supports administrative revocation of all
state for a client. It marks that client revoked just like it would have if
the lease had expired, in the stable storage restart file and won't allow that
client to recover any state during Grace. It happens that my clientid has a
field in it that increments for each clientid (and associated stateid), so
it can return NFS4ERR_EXPIRED for any of that state until after a reboot.

I do currently allow the client to establish new state after a
SETCLIENTID/SETCLIENTID_CONFIRM, but the clientids/stateids are recognized
as distinct from the ones issued before the revocation.

Does this sound ok? rick
ps: I used "-->" for "this implies".

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4