Date: Sun, 7 Jul 2002 20:56:38 +0400 (MSD) From: "Roman V. Palagin" <romanp@unshadow.net> To: John Polstra <jdp@polstra.com> Cc: stable@FreeBSD.ORG Subject: Re: NFS errors at high hz values with TCP mounts Message-ID: <20020707205408.Y416-100000@room101.wuppy.net.ru> In-Reply-To: <200207062254.g66MsJPj000565@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 6, at 3:54pm -0700, John Polstra wrote:
> > > Here's what happens when I try to copy a 512 kbyte file from the
> > > hz=10000 client to a server that is NFS-mounted:
> > >
> > > thin$ dd if=/dev/zero of=/mnt/foo count=1000
> > > dd: /mnt/foo: Resource temporarily unavailable
> > > 61+0 records in
> > > 60+0 records out
> > > 30720 bytes transferred in 0.000996 secs (30843571 bytes/sec)
> >
> > I forget to mention that this message appears in the dmesg output on
> > the client machine:
> >
> > nfs send error 35 for server strings:/usr/home/jdp
> >
> > It comes from sys/nfs/nfs_socket.c line 499.
>
> Sorry for the extended conversation with myself. :-) I think I
> found the bug. In nfs_connect() at line 300 of sys/nfs/nfs_socket.c
> we have this code:
>
> so->so_rcv.sb_timeo = (5 * hz);
> so->so_snd.sb_timeo = (5 * hz);
>
> But sb_timeo has type "short", which overflows when hz is 10000.
>
> This is in struct sockbuf. I don't think it would break binary
> compatibility with existing 3rd party modules to change it to type
> "long". Are there any contrary opinions?
I see this problem with HZ=1000, overflow doesn't occured in this
situation... May be problem lies somewhere else?
- Roman
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020707205408.Y416-100000>