Date: Thu, 30 Sep 1999 07:13:23 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Mike Tancsa <mike@sentex.net> Cc: stable@FreeBSD.ORG Subject: Re: State of NFS in STABLE Message-ID: <199909301414.HAA94029@cwsys.cwsent.com> In-Reply-To: Your message of "Wed, 29 Sep 1999 22:24:53 EDT." <4.1.19990929221225.07e02a50@granite.sentex.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <4.1.19990929221225.07e02a50@granite.sentex.ca>, Mike Tancsa
writes:
>
> I have an application where having NFS mounts is required. Looking back
> through the recent archives, there still seem to be issues with NFS.
> However, what is unclear is if this is primarily due to particular types of
> I/O... In otherwords, if the nfs mount is Read Only, will I avoid the
> majority of problems ? Or if I use V2 ? Or V3 ?
I use NFS on my network at home and at work. I've forced the use of V2
mounts for about 2-3 years (since 2.2), prior to that I used the
default that was shipped with 2.0.5 and 2.1.
At work I share files between Solaris, Tru64-UNIX, Linux, and FreeBSD.
The only issues I've had are,
1) FreeBSD NFS may be slower than Solaris or Tru64-UNIX NFS. I haven't
measured it. This is just a "seat of the pants" impression.
2) When sharing files from my desktop FreeBSD system, which has ipfw
enabled, to a Tru64-UNIX system at an earthquake resistant site
which
is 5 hops away, Tru64-UNIX MTU discovery, which is broken, tends to
mangle NFS packets (and Legato packets too). Reducing the NFS
buffer
size to ~ 1400 fixes this.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca
ITSD Cy.Schubert@gems8.gov.bc.ca
Province of BC
"e**(i*pi)+1=0"
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?199909301414.HAA94029>