Date: Tue, 21 Sep 1999 20:59:13 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: "David E. Cross" <crossd@cs.rpi.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: missing files with NFSv3 and Solaris2.7 machine... Message-ID: <199909220359.UAA10568@apollo.backplane.com> References: <199909211642.MAA44933@cs.rpi.edu> <37E8204C.25A1FFAE@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909220359.UAA10568>