Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Dec 1998 01:44:00 +0100
From:      Bernd Walter <ticso@cicely.de>
To:        Charles Owens <owensc@enc.edu>, hackers@FreeBSD.ORG
Subject:   Re: NFS thoughts
Message-ID:  <19981216014400.20185@cicely.de>
In-Reply-To: <Pine.BSF.3.96.981215092411.2552B-100000@itsdsv2.enc.edu>; from Charles Owens on Tue, Dec 15, 1998 at 10:10:16AM -0500
References:  <Pine.BSF.3.96.981215092411.2552B-100000@itsdsv2.enc.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 15, 1998 at 10:10:16AM -0500, Charles Owens wrote:
> On Mon, 14 Dec 1998, Bernd Walter wrote:
> 
> > I saw the same on my private hosts.
> > Everythings the same to your case instead that I have a 100MBit FreeBSD Router
> > between them. All lines are running Full-Duplex Point-to-Point.
> > In my case I have a syslogentry telling me about a server down under some load
> > and it took minutes till it says that the server is up again.
> > It happend when using NFS3/TCP at this moment I'm using NFS2/UDP and it won't
> > hang.
> 
> I was at the Usenix LISA conference last week and in one of the
> tutorials the issue of NFSv3/TCP stability and interoperability came
> up.
> 
> One user reported the SGI<->Solaris and even SGI<->SGI NFSv3 mounts
> were flakey (with similar symptoms as described here).  He eventually
> traced the problem to the NFSv3/TCP's use of larger buffersizes.
> These result in more intense bursts of network activity which would at
> times overrun buffers in his Ethernet switch.   He convinced his
A switch should never have overruns.
If a buffer gets full a switch is able to top receiving.
On Half-Duplex lines a switch usualy create some collinsions on the receiving
port top slow down thne sender.
On Full-Duplex Ports there's a compareable method for doing the same.
In any case it's a broken switch, nic, nic-driver or configuration of them.
Very often people don't check their ethernets for errors due to
Duplex-missonfigurations

> network vendor to replace the switch with another with deeper buffers,
> and his problem went away!
> 
> With the original switch he found that the default 32K read/write
> buffer size (as compared to UDP's default of 8K) was too much, but by
> limiting it to 16K he was able to get by, but with some reduction in
> performance.
> 
> Could this be the issue that is plaguing our attempts to use NFSv3
> with FreeBSD?  Or are there other known defects that are at fault.
In my case there is only a FreeBSD Router between them.
All Line are without any known problems.

> 
> I'm guessing that with FreeBSD we'd use the -r and -w options of mount_nfs
> to limit the read and write buffer sizes, though the manpage description
> isn't quite as informative as what's provided with the Solaris:
> 
>           rsize=n        Set the read buffer  size  to  n  bytes.
>                          The  default  value  is 32768 when using
>                          Version 3 of  the  NFS  protocol.   When
>                          using  Version  2,  the default value is
>                          8192.
> 
> Does this mount_nfs option from Solaris indeed work the same way as
> FreeBSD's -r option?
> 
> later,
> ---
> -------------------------------------------------------------------------
>   Charles N. Owens                               Email:  owensc@enc.edu
>                                              http://www.enc.edu/~owensc
>   Network & Systems Administrator
>   Information Technology Services  "Outside of a dog, a book is a man's
>   Eastern Nazarene College         best friend.  Inside of a dog it's 
>                                    too dark to read." - Groucho Marx
> -------------------------------------------------------------------------
> 
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message

-- 
  B.Walter


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981216014400.20185>