Crap, I just sent out an incomplete message. Let me pick up from where
I left off. Here's a diff that shows the changes I made to nfs_vfsops.c:
*** nfs_vnops.c.orig Thu Jul 29 22:46:28 1999
--- nfs_vnops.c Thu Jul 29 22:36:39 1999
***************
*** 2342,2348 ****
IFTODT(VTTOIF(np->n_vattr.va_type));
ndp->ni_vp = newvp;
cnp->cn_hash = 0;
! for (cp = cnp->cn_nameptr, i = 1; i <= len;
i++, cp++)
cnp->cn_hash += (unsigned char)*cp * i;
cache_enter(ndp->ni_dvp, ndp->ni_vp, cnp);
--- 2342,2351 ----
IFTODT(VTTOIF(np->n_vattr.va_type));
ndp->ni_vp = newvp;
cnp->cn_hash = 0;
! /*for (cp = cnp->cn_nameptr, i = 1; i <= len;*/
! if (len != cnp->cn_namelen)
! printf("bogus: %d %d\n", len, cnp->cn_namelen);
! for (cp = cnp->cn_nameptr, i = 1; i <= cnp->cn_namelen;
i++, cp++)
cnp->cn_hash += (unsigned char)*cp * i;
cache_enter(ndp->ni_dvp, ndp->ni_vp, cnp);
Basically, at some point, the code tries to calculate a new hash value
(what for I don't know) of a name that was read from the directory
listing. However it uses "len" as the length of the name, which for
some reason I can't understand turns out not matching the cn_namelen
value in cnp. The "bogus" printf shows about a half dozen occasions
where len and cn_namelen don't agree. Sometimes "len" is larger
than "cnp->cn_namelen," sometimes it's smaller. By using cn_namelen
instead of len, everything seems to work correctly. It looks like
this loop makes more than one pass over directory entries, so it could
be that len is sometimes stale. If you can make sense of why this
happens, I would appreciate it: I don't like to commit changes when
I don't fully understand what's going on.
> Presumably this will not fix the SGI client. I've no idea what the
> problem there is. There may be a bug in the SGI client or there may
> be a bug in the client & server implementation of the protocol in FreeBSD.
Er, I think you misunderstood: there's nothing wrong with the SGI in
this case. I mentioned it because I was using it as a _server_ when
testing the client side readdirplus support: the behavior with the
SGI server was slightly different from another FreeBSD server (the
FreeBSD client blew up right away with the SGI acting as server,
where it took a little longer with the FreeBSD server). I think this
was just a consequence of the filesystems being laid out differently.
The patched FreeBSD client works fine now with the SGI server.
-Bill
--
=============================================================================
-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home: [EMAIL PROTECTED] | Columbia University, New York City
=============================================================================
"It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=============================================================================
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
