From owner-freebsd-current Thu Sep 30 13: 7:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 30FC314D7B for ; Thu, 30 Sep 1999 13:07:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA13494; Thu, 30 Sep 1999 13:07:33 -0700 (PDT) (envelope-from dillon) Date: Thu, 30 Sep 1999 13:07:33 -0700 (PDT) From: Matthew Dillon Message-Id: <199909302007.NAA13494@apollo.backplane.com> To: freebsd-current@FreeBSD.ORG Subject: NFS mod for solaris committed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message