Re: [nfsv4] re: re: NFS4ERR_ADMIN_REVOKE

Spencer Shepler <> Fri, 01 October 2004 22:58 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA06114 for <>; Fri, 1 Oct 2004 18:58:40 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CDWUu-0006sN-64 for; Fri, 01 Oct 2004 19:07:33 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CDW1i-0006QF-13; Fri, 01 Oct 2004 18:37:22 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1CDVoq-0000n1-Pa for; Fri, 01 Oct 2004 18:24:04 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA01721 for <>; Fri, 1 Oct 2004 18:24:02 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CDVxO-0001do-Au for; Fri, 01 Oct 2004 18:32:54 -0400
Received: from centralmail1brm.Central.Sun.COM ([]) by (8.12.10/8.12.9) with ESMTP id i91MO335023745 for <>; Fri, 1 Oct 2004 15:24:03 -0700 (PDT)
Received: from (nfsclient.Central.Sun.COM []) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i91MO2jW005788 for <>; Fri, 1 Oct 2004 16:24:03 -0600 (MDT)
Received: from (localhost []) by (8.13.1+Sun/8.13.1) with ESMTP id i91MO2J4025551 for <>; Fri, 1 Oct 2004 17:24:02 -0500 (CDT)
Received: (from shepler@localhost) by (8.13.1+Sun/8.13.1/Submit) id i91MO2aT025550 for; Fri, 1 Oct 2004 17:24:02 -0500 (CDT)
Date: Fri, 01 Oct 2004 17:24:02 -0500
From: Spencer Shepler <>
Subject: Re: [nfsv4] re: re: NFS4ERR_ADMIN_REVOKE
Message-ID: <>
Mail-Followup-To: Spencer Shepler <>,
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4

On Mon, wrote:
> > We use the NFS4ERR_ADMIN_REVOKED error for indicating when state 
> > [clientid, stateid (either open,lock, or delegation)] has been revoked and 
> > will no longer be accepted by the server.
> Yep. My main concern in this area was "how permanent" this has to be. Which
> you've addressed later. (Put another way when/if the NFS4ERR_ADMIN_REVOKED
> can be replaced by NFS4ERR_EXPIRED.)

Clientid doesn't apply and I think that is understood in that if the
clientid is revoked then NFS4ERR_EXPIRED should be returned, not

> > Once the client as a whole has been marked as revoked, we do not do any 
> > renewing of it.
> > Once the client's state structures are reclaimed (which may be some time 
> > after it has really "expired"), then the client would get back the 
> > NFS4ERR_EXPIRED error.
> This sounds exactly like what my current code will do. (I, also, don't
> expire the client until sometime after the expiry.)
> > The only way for the client to get past this client wide revoke is to then 
> > issue a SETCLIENTID/SETCLIENTID_CONFIRM sequence. This will purge all 
> > revoked state from the client and it can begin anew. Do you do something 
> > like this OR do you make the revoke permanent? That is, require 
> > administrative intervention to lift the embargo on the bad client ?
> 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.

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

> > We do not tie the revokes to a specific open owner. The main reason being 
> > is that the server hands out clientids and stateids, but not "open 
> > owners". The server only revokes things it hands out.
> This sounds like the only place where our current code differs. I used
> the open/lockowner since it was explicitly referred to in the RFC. (My
> assumption was that the author was thinking that an open/lockowner equates
> to a client process/task that went south without releasing the state as
> it should.) btw, when I say "revoke an openowner" I mean that all stateids
> for all opens and lockowners associated with that openowner will be revoked
> and use of all those stateids will get NFS4ERR_ADMIN_REVOKED.
> My current code could easily be changed to revoke opens instead of openowners.
> Do others see this as an issue? (ie. Does it matter w.r.t the protocol whether
> the openowner with all associated opens or the individual opens, gets revoked?)

Administratively, I would expect that files or shares/exports are the
unit of revocation.  The admin is unlikely to care about openowners
unless there seems to something broken with the NFSv4 client and it
that case the entire client might as well be revoked.


nfsv4 mailing list