[nfsv4] re: re: NFS4ERR_ADMIN_REVOKE

rick@snowhite.cis.uoguelph.ca Mon, 27 September 2004 16:02 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09785 for <nfsv4-web-archive@ietf.org>; Mon, 27 Sep 2004 12:02:01 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBy4d-0000Kn-9Z for nfsv4-web-archive@ietf.org; Mon, 27 Sep 2004 12:09:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBxtk-0005xs-8h; Mon, 27 Sep 2004 11:58:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBxlm-0003GF-Rd for nfsv4@megatron.ietf.org; Mon, 27 Sep 2004 11:50:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09104 for <nfsv4@ietf.org>; Mon, 27 Sep 2004 11:50:27 -0400 (EDT)
From: rick@snowhite.cis.uoguelph.ca
Received: from moe.cs.uoguelph.ca ([131.104.96.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBxtQ-00006D-La for nfsv4@ietf.org; Mon, 27 Sep 2004 11:58:25 -0400
Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by moe.cs.uoguelph.ca (8.12.11/8.12.11) with ESMTP id i8RFoSpg027729 for <nfsv4@ietf.org>; Mon, 27 Sep 2004 11:50:28 -0400
Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id LAA12550 for nfsv4@ietf.org; Mon, 27 Sep 2004 11:51:35 -0400 (EDT)
Date: Mon, 27 Sep 2004 11:51:35 -0400
Message-Id: <200409271551.LAA12550@snowhite.cis.uoguelph.ca>
To: nfsv4@ietf.org
X-Spam-Scanner: SpamAssassin 2.63 (http://www.spamassassin.org/) on moe.cs.uoguelph.ca
X-Spam-Score: hits=0.9
X-Spam-Tests: J_CHICKENPOX_44,NO_REAL_NAME
X-Spam-Status: Suspected
X-Scanned-By: MIMEDefang 2.39
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Subject: [nfsv4] re: re: NFS4ERR_ADMIN_REVOKE
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
Sender: nfsv4-bounces@ietf.org
Errors-To: nfsv4-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002

> 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.)

> 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.

> 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?)

Have a good week, rick

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