Oh, I forgot to email current on this...
I've #if 0'd out the NFSERR_BAD_COOKIE code that is partially responsible
for the solaris interoperability problems
I went through the code very carefully and determined that my previous
understanding was just plain wrong. As far as I can tell, the directory
blocks do not get renumbered by the server so it should be ok to not be
so strict when dealing with the cookies.
In anycase, I would like the people with solaris NFS clients who have
encountered this problem to test with this change before I MFC it from
current to stable. It's a very simple patch and you can patch it
into your -STABLE's (if you are using stable) to test it very easily.
I would like to know whether this fixes the problem w/ solaris clients.
It would also be nice if more extensive testing between FreeBSD clients
and servers were done, but that isn't as critical. It's very hard to
reproduce the problem with a FreeBSD client due to the way FreeBSD clients
scan directories.
So, synopsis: The patch has been committed to current but not yet
committed to stable.
-Matt
nfs/nfs_serv.c
revision 1.86
date: 1999/09/29 17:14:58; author: dillon; state: Exp; lines: +5 -1
Make FreeBSD less conservative in determining when to return a cookie
error for a directory. I have made this change after a great deal of
review although I cannot be absolutely sure that this meets the spec.
The issue devolves into whether changes in an underlying (UFS) directory
can cause NFS directory blocks to be renumbered. My read of the code
indicates that NFS directory blocks will not be renumbered, which means
that the cookies should still remain valid after a change is made to
the underlying directory. This being the case, a cookie error should
not be returned when a change is made to the underlying directory and,
instead, the NFS client should rely on mtime detection to invalidate and
reload the directory.
The use of mtime is problematic in of itself, due to insufficient
resolution, which is why I believe the original conservative error
handling was done. Still, there have been dozens of bug reports by
people needing solaris<->FreeBSD interoperability and these have to
be accomodated.
Index: nfs_serv.c
===================================================================
RCS file: /home/ncvs/src/sys/nfs/nfs_serv.c,v
retrieving revision 1.85
retrieving revision 1.86
diff -u -r1.85 -r1.86
--- nfs_serv.c 1999/09/17 05:57:57 1.85
+++ nfs_serv.c 1999/09/29 17:14:58 1.86
@@ -34,7 +34,7 @@
* SUCH DAMAGE.
*
* @(#)nfs_serv.c 8.8 (Berkeley) 7/31/95
- * $FreeBSD: src/sys/nfs/nfs_serv.c,v 1.85 1999/09/17 05:57:57 dillon Exp $
+ * $FreeBSD: src/sys/nfs/nfs_serv.c,v 1.86 1999/09/29 17:14:58 dillon Exp $
*/
/*
@@ -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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
