:On Mon, 2 Aug 1999, Alfred Perlstein wrote:
:
:> } \
:> if (fhlen != 0) { \
:> nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
:> bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
:> if ((nfsd->nd_flag & ND_NFSV3) == 0) \
:> nfsm_adv(NFSX_V2FH - NFSX_V3FH); \
:> } \
:> }
:
:...
:
:> it then rewinds the mbuf pointers (i think) because of the
:> over "dissection" above.
:> ---
:>
:> why does it do the copy, then rewind it, it seems like it knows
:> it's doing something wrong and instead of fixing it, it just
:> compensates after the fact.
:
:yes, replying to my own message.
:
:the only thing i can think of is that the extra data is safely
:ignored because the routines that use these macros seem to
:pass the version of NFS to all the function that they call...
:
:however unless i'm wrong (which i probably am) nfsV2 stuff
:could be made faster if it was correctly noted and less data
:was copied. It would also DTRT and not access data it isn't
:supposed to :)
:
:it seems like all of the V3 handles are the same length so
:there isn't much to do there...
:
:-Alfred
Well, I must say that it certainly looks like a bug. It is not going
to blow anything up since the nfsm_dissect() will break out if it runs
out of buffer space, but it certainly seems inefficient. I am somewhat
loath to fix anything in NFS that does not create a demonstrateable
problem for fear of creating new problems, though, it is quite possible
that the server code depends on the extra junk in the file handle for
V2 mounts - A full audit of nfs_nqlease.c and nfs_serv.c would be
necessary before this could be fixed.
-Matt
Matthew Dillon
<[email protected]>
To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-hackers" in the body of the message
