[nfsv4] use of NFS4ERR_ADMIN_REVOKED
rick@snowhite.cis.uoguelph.ca Sun, 26 September 2004 19:23 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 PAA25730 for <nfsv4-web-archive@ietf.org>; Sun, 26 Sep 2004 15:23:39 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBek0-0006JO-C1 for nfsv4-web-archive@ietf.org; Sun, 26 Sep 2004 15:31:24 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBeYa-0003a4-1v; Sun, 26 Sep 2004 15:19:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBeYH-0003WO-0h for nfsv4@megatron.ietf.org; Sun, 26 Sep 2004 15:19:17 -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 PAA25456 for <nfsv4@ietf.org>; Sun, 26 Sep 2004 15:19:15 -0400 (EDT)
From: rick@snowhite.cis.uoguelph.ca
Received: from moya.cs.uoguelph.ca ([131.104.96.180]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBefg-0006FR-I8 for nfsv4@ietf.org; Sun, 26 Sep 2004 15:26:57 -0400
Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by moya.cs.uoguelph.ca (8.12.11/8.12.11) with ESMTP id i8QJJ6oj001506 for <nfsv4@ietf.org>; Sun, 26 Sep 2004 15:19:06 -0400
Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id PAA98399 for nfsv4@ietf.org; Sun, 26 Sep 2004 15:20:15 -0400 (EDT)
Date: Sun, 26 Sep 2004 15:20:15 -0400
Message-Id: <200409261920.PAA98399@snowhite.cis.uoguelph.ca>
To: nfsv4@ietf.org
X-Spam-Scanner: SpamAssassin 2.63 (http://www.spamassassin.org/) on moya.cs.uoguelph.ca
X-Spam-Score: hits=0.3
X-Spam-Tests: NO_REAL_NAME
X-Spam-Status: Suspected
X-Scanned-By: MIMEDefang 2.39
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Subject: [nfsv4] use of NFS4ERR_ADMIN_REVOKED
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: 082a9cbf4d599f360ac7f815372a6a15
In sec. 12: NFS4ERR_ADMIN_REVOKED Due to andministrator intervention, the lockowner's record locks, share reservations, and delegations have been revoked by the server. The above statement seems to suggest that the revocation is related to a lockowner, but there are other places in the RFC that seem to imply otherwise. For example, Renew can return NFS4ERR_ADMIN_REVOKED although it takes a clientid and not a stateid. Also, a delegation isn't really related to a lockowner, although it is initially issued due to an Open associated with an open/lockowner. The only other place I could find that discusses this in the RFC (para. 4 of sec. 8.8), doesn't seem to clarify this, although it does indication that the revocation may only apply to one lockowner. As such, here is what I'm currently implementing w.r.t. returning NFS4ERR_ADMIN_REVOKED and am wondering if I'm off track yet again:-) I have two type of revocations: 1 - all state for a client, after which the server returns NFS4ERR_ADMIN_REVOKED for all routines that can do so for that clientid and any associated stateid. (Close, Lock, LockU, Open, OpenConfirm, OpenDowngrade, Read, Setattr, Write, ReleaseLockOwner) It seems slightly strange that LockT isn't allowed to return it, but I went with "assume all locks are now from conflicting clients, since that client is revoked" and then test for conflicts. After the lease expires, the client goes away and further use of the clientid or associated stateids becomes NFS4ERR_EXPIRED. (Does this sound correct or should the Renew do a renewal even though it returns NFS4ERR_ADMIN_REVOKED.) * I can only see this being used when a client is somehow misbehaving and causing resource exhaustion or similar. 2 - byte range lock owner for a given stateid (which implies the associated clientid). For this case, the error would only be returned for Ops that used that stateid and NOT ones using the associated clientid, such as Renew. (Does that make sense, or should Renew return the error in this case?) It would do this persistently, until the lockowner state went away, via either a ReleaseLockOwner or a Close on the associated Open. 2a - open_owner (which implies all associated stateids for Opens and lockowners associated with those Opens). For this case, the error would be returned for all Ops using all of those stateids, but NOT Renew (same as 2). At some point, the OpenOwner would be released, since it has no Opens and the stateids would get NFS4ERR_EXPIRED after that. This one is problematic, in that it isn't obvious how long the OpenOwner with revoked flag set needs to persist? Alternatively, I could hold onto the OpenOwner until Close is done on all the associated Opens. This would guarantee that the client sees NFS4ERR_ADMIN_REVOKED, but also requires that the client bother to Close any Open who's stateid gets a NFS4ERR_ADMIN_REVOKED instead of just assuming it is no longer usable. (I may have missed it, but I can't see this spelled out in the RFC.) Thanks in advance for any comments, rick _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4