Alfred Perlstein wrote:
> On Wed, 7 Jul 1999, Peter Wemm wrote:
>
> > Alfred Perlstein wrote:
> > >
> > > I just cvsup'd today hoping that all the NFS fixes that went in
> > > recently would have alleviated (sp?) the hangs I've been getting
> > > while building things in ports for the last couple of months.
> > >
> > > It used to be that just NFS would hang, now it seems to crash the
> > > entire box.
> > >
> > > server:/vol/extra/ports /usr/ports nfs rw,noauto,bg,intr,nfsv3,t
cp,-
> > r=3
> > > 2768,-w=32768 0 0
> > > server:/vol/extra/ncvs /home/ncvs nfs rw,noauto,bg,intr,nfsv3,t
cp,-
> > r=3
> > > 2768,-w=32768 0 0
> > > server:/vol/wd0 /vol/wd0 nfs rw,noauto,bg,intr,nfsv3,t
cp,-
> > r=3
> > > 2768,-w=32768 0 0
> > >
> > > are the mount points.
> > >
> > > attempting to compile xscreensaver has triggered it twice in a row
> > > /usr/ports is mounted off "server" (a freebsd -current box) and
> > > doing the make will kill the machine.
> > >
> > > Once I figure out where the heck I have the console redirected
> > > I'll have something more substantial.
> >
> > You have a block size of 32K, I'll bet it's 'Bad nfs svc reply' in
> > nfs_syscalls.c. This is triggered when the READDIRPLUS op generates
> > an oversized reply and it triggers the sanity check.
>
> odd, shouldn't it know not to violate its own sanity checks? Just
> throttle down the requests, or spit out an error?
Well, I still am having trouble getting my head around what's going on.
In a nutshell, the code goes to a fair bit of trouble to not generate a
packet that violates the protocols, and yet it still does, by a long shot.
I'm setting up to try and reproduce this so I can catch it live rather than
long afterwards.
> > Change it to 16K and I think it'll work. Otherwise change the panic to a
> > printf(), but that is sweeping the problem under the carpet and might just
> > give the client indigestion. It does stop the server crashing though.
>
> I'll try that, thanks, set my -r and -w to 16k. Um something odd
> though, from the code:
>
> if (siz <= 0 || siz > NFS_MAXPACKET) {
> printf("mbuf siz=%d\n",siz);
> panic("Bad nfs svc reply");
> }
>
> then earlier:
> nfsproto.h:#define NFS_MAXPKTHDR 404
> nfsproto.h:#define NFS_MAXPACKET (NFS_MAXPKTHDR + NFS_MAXDATA)
> nfsproto.h:#define NFS_MAXDATA 32768
>
> isn't 32k within the safe limits, or sometimes when building the RPC
> reply it can just get too big?
It's running over by at least 250 bytes or so. ie: 32K + 680, which is
more than 32K + 404. I have not got the protocol maps handy so I'm not yet
sure if the limits are wrong, or the request is wrong, or the readdirplus
code is wrong. In any case, *something* is wrong. :-)
> Oh, one more thing, I'm getting "device busy" even when using -f
> during my unmount of wedged nfs mounts, all I needed to do was
> kill -9 a shell sitting in that dir, but shouldn't that be
> unnessesary?
Umm.. what were you unmounting? server:/mount or the /localmount? There
are some well known problems with trying to unmount /localmount for a
wedged mount - the damn code stat's it and hangs itself. Trying to fix
this and yet accomodate all the other tweaks for handling symlinks
(ie: /dev/cdrom -> /dev/cd0a) etc style hacks got me rather confused last
time.
Also, the VM has changed a bit over the last few months, deadfs may not be
finding all the hooks into the VFS that might be still there.
> thanks for your patience,
> -Alfred
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
