From nfsv4-bounces@ietf.org Tue Sep 21 18:10:45 2004 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 SAA06454 for ; Tue, 21 Sep 2004 18:10:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9swu-0008Cw-Dq for nfsv4-web-archive@ietf.org; Tue, 21 Sep 2004 18:17:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9sRD-0005HN-1a; Tue, 21 Sep 2004 17:44:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9sJd-0003Z8-IJ for nfsv4@megatron.ietf.org; Tue, 21 Sep 2004 17:36:49 -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 RAA02328 for ; Tue, 21 Sep 2004 17:36:47 -0400 (EDT) Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9sQ5-00079v-2K for nfsv4@ietf.org; Tue, 21 Sep 2004 17:43:29 -0400 Received: from citi.umich.edu (dumaguete.citi.umich.edu [141.211.133.51]) by citi.umich.edu (Postfix) with ESMTP id 1F53E1BBBA for ; Tue, 21 Sep 2004 17:36:43 -0400 (EDT) To: nfsv4@ietf.org From: Jim Rees Date: Tue, 21 Sep 2004 17:36:43 -0400 Message-Id: <20040921213643.1F53E1BBBA@citi.umich.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [nfsv4] CITI Combined BSD client available X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad You'll find the Combined BSD client, including gss, for Darwin and FreeBSD, on our NFSv4 web page. http://www.citi.umich.edu/projects/nfsv4/ I'm afraid it comes with almost no support or documentation, but we can probably answer reasonable questions. Please let us know if you do anything with this. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Sep 22 03:07:24 2004 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 DAA07923 for ; Wed, 22 Sep 2004 03:07:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA1KN-0008CS-K4 for nfsv4-web-archive@ietf.org; Wed, 22 Sep 2004 03:14:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA1CR-0001sH-9s; Wed, 22 Sep 2004 03:05:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA191-00015N-H3 for nfsv4@megatron.ietf.org; Wed, 22 Sep 2004 03:02:27 -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 DAA07623 for ; Wed, 22 Sep 2004 03:02:25 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.197] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA1FX-00088M-Bu for nfsv4@ietf.org; Wed, 22 Sep 2004 03:09:12 -0400 Received: by mproxy.gmail.com with SMTP id 73so1656514rnl for ; Wed, 22 Sep 2004 00:02:25 -0700 (PDT) Received: by 10.38.24.80 with SMTP id 80mr2126720rnx; Wed, 22 Sep 2004 00:02:25 -0700 (PDT) Received: by 10.38.92.25 with HTTP; Wed, 22 Sep 2004 00:02:24 -0700 (PDT) Message-ID: <2205e3b8040922000251529b60@mail.gmail.com> Date: Wed, 22 Sep 2004 12:32:24 +0530 From: Prasanna Wakhare To: nfsv4@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [nfsv4] readpage_NFS X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Prasanna Wakhare List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfsv4-bounces@ietf.org Errors-To: nfsv4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Hi, I'm goin through nfs readpage firstly i'm not clear about readpage. But only i know that we have to allocate the page b4 firing RPC read,or generic_file_read, which searches page in page cache. In nfs_readpage_sync,there is a call to read RPC without allocating page ,but page is allocated in nfs_readpage_async,how without allocating page the read is call in nfs_readpage_sync,and could anyone clear my ideas on readpage in NFS as it is clear in ext2 and local filesystems. Thanks Prasanna _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Sep 26 15:23:39 2004 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 ; 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 ; 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 ; 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 (EDT) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nfsv4-bounces@ietf.org Mon Sep 27 12:02:01 2004 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 ; 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 ; 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 ; 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 (EDT) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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