From owner-freebsd-hackers Tue Sep 21 20:59:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BC84E14ED3 for ; Tue, 21 Sep 1999 20:59:14 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA10568; Tue, 21 Sep 1999 20:59:13 -0700 (PDT) (envelope-from dillon) Date: Tue, 21 Sep 1999 20:59:13 -0700 (PDT) From: Matthew Dillon Message-Id: <199909220359.UAA10568@apollo.backplane.com> To: "Daniel C. Sobral" Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: missing files with NFSv3 and Solaris2.7 machine... References: <199909211642.MAA44933@cs.rpi.edu> <37E8204C.25A1FFAE@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :As I recall, we had two alternatives. First, knowingly not comply to :the spec, because Solaris doesn't handle it. Second, change the way :we read directories so we can avoid doing things in the way Solaris :can't handle. The latter is a very sore spot, and not trivial. : :I was under the impression, though, that Matthew Dillon had done :something about it. I haven't done anything about it yet. I haven't been able to figure out whether the server can safely ignore checking the file revision (which is what is causing it to report NFSERR_BAD_COOKIE). Just for kicks, try the patch below. What I'm not sure about is whether the VOP_READDIR() call the server makes can get out of sync with what was reported to the client in the past when a file is created or deleted in the directory. What I mean by 'out of sync' here is whether it can create a situation where it reports directory entries in one directory block that had previously been reported in another. The other case I'm not sure about is what happens when the directory on the server has a white-out directory entry at the very beginning of a block, causing it to report a cookie that occurs a little later in the block, and then a file is created on the server which converts that white-out entry with a real entry. If the client re-requests the directory block it will give the server the cookie for what is now the second file in the directory block, not the first file. The server then ignores the directory entry in that directory block that had just been created (that used to be white-out), and generates a reply to the client that is no longer in sync for that directory block with what the server would report if the entire directory was rescanned. -Matt Matthew Dillon Index: nfs/nfs_serv.c =================================================================== RCS file: /home/ncvs/src/sys/nfs/nfs_serv.c,v retrieving revision 1.85 diff -u -r1.85 nfs_serv.c --- nfs_serv.c 1999/09/17 05:57:57 1.85 +++ nfs_serv.c 1999/09/22 03:51:36 @@ -3032,11 +3032,13 @@ nqsrv_getl(vp, ND_READ); if (v3) { error = getret = VOP_GETATTR(vp, &at, cred, procp); +#if 0 /* * XXX This check may be too strict for Solaris 2.5 clients. */ if (!error && toff && verf && verf != at.va_filerev) error = NFSERR_BAD_COOKIE; +#endif } if (!error) error = nfsrv_access(vp, VEXEC, cred, rdonly, procp, 0); @@ -3312,11 +3314,13 @@ goto nfsmout; } error = getret = VOP_GETATTR(vp, &at, cred, procp); +#if 0 /* * XXX This check may be too strict for Solaris 2.5 clients. */ if (!error && toff && verf && verf != at.va_filerev) error = NFSERR_BAD_COOKIE; +#endif if (!error) { nqsrv_getl(vp, ND_READ); error = nfsrv_access(vp, VEXEC, cred, rdonly, procp, 0); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message