root wrote:
>
> On Thu, 19 Jun 2003 15:18:39 -0700, Patch wrote:
>
> > "root" <root@jonspc.jonspc> wrote in message
> > news:<pan.2003.06.14.14.48.49.369661@jonspc.jonspc >...
> >> On Sat, 14 Jun 2003 01:24:21 +0000, Fanying Jen wrote:
> >>
> >> > I am a senior system administrator at Lille Corp whom provides thin
> >> > client (LTSP or Linux Terminal Server Project) Linux solutions to the
> >> > medical industry. We have a very serious problem with the reliability
> >> > of NFS over both Fast Ethernet (100BaseT) and WANs including T1s
> >> > point to point, and IPSEC VPNs where the other node is on business
> >> > cable modem. The customer is a mid size medical assoicate with over
> >> > three hundred staff members and two hundred terminals and PC, mostly
> >> > Linux spread over three states.
> >> >
> >> > There are two major problems with NFS. One is NFS crashing the entire
> >> > three hundred person organization in one swoop and bringing it to a
> >> > grinding halt in front of users and the patients (customers of the
> >> > customer) which is not good particularily since Linux is branded to
> >> > be more stable.
> >> >
> >> > The other major problem is when NFS is not crashing systems, it
> >> > looses data particularily with OpenOffice costing many man hours of
> >> > work. In addition, even simple commands like "ls" have trouble
> >> > displaying the entire directory and users sometimes get into a stale
> >> > lock as well.
> >> >
> >> > I will provide the network topology along with the system specs,
> >> > configuration, and the software components.
> >> >
> >> > Network Topology
> > ...
> > ... (text removed)
> > ...
> >> >
> >> > NFS Problem 1 (Crashing)
> >> >
> >> > The LTSP would create stale locks and eventually the LTSP server
> >> > crashes. Furthermore, data is corrupted during the process.
> >> >
> >> > NFS Problem 2 (Corruption)
> >> >
> >> > This happens mostly in OpenOffice, more than once, data gets
> >> > corrupted and when working with both Microsoft and native OpenOffice
> >> > formats. On full local workstations where the files are save to the
> >> > local disk, this does not happen. The office docuements are normally
> >> > saved to an NFS filesystem.
> >> >
> >> > NFS Problem 3 (Performance)
> >> >
> >> > NFS is very slow over T1 and cable links but is just fine on the
> >> > Local Fast Ethernet. It is slow enough to either knock people off or
> >> > cause write errors. We are thinking the hubs play a major role and
> >> > are replacing with high end managed switches. However we believe that
> >> > there is more than meets the eye and the T1 also has something to do
> >> > with.
> >> >
> >> > Summary
> >> >
> >> > Those are the problems and I give as much information as I possibly
> >> > can. I would be appreciate if anyone can point us in the right
> >> > direction. We commercial organization and our customer are also
> >> > commercial and we all want Linux to success not only on the server
> >> > but also on the desktop. This customer is one of the boldest I have
> >> > seen in the embracing of Linux on the desktop and we want them to
> >> > success to the fullest, therefore we are asking for your assistance
> >> > so we can do what many people say you can't, make money with Linux!
> >> >
> >> > Thank you and Sincerely,
> >> > Fanying Jen
> >> > Senior System Administration
> >> > Lille Corp.
> >>
> >> [Why are you running a UDP LAN network on a WAN then looking suprised
> >> when it doesnt work. NFS is not suitable for WAN based applications,
> >> the linux version of NFS isnt even as "not good" as Suns NFS.
> >>
> >> You could try an IP socket implementation of NFS (They do exist) or a
> >> better solution is to use SMB instead. SMB is not a sexy network
> >> protocol, but it is session based and doesn't pretend to be stateless.
> >> Linux works with smb in the same way as NFS so you can put the mounts
> >> into fstab, the only difference is the server needs the shares defined
> >> in smb.conf not /etc/exports. It only uses a couple of sockets (the
> >> problem with NFS is it negetioates a socket (UDP) using portmap, makes
> >> firewalls fun - might be part of your problem infact)
> >>
> >> NFS has many many defects for WANS - it expects full duplex (talk and
> >> listen at the same time). It uses UDP and doesn't retry fails with 100%
> >> accuracy. It uses very large frames, useless for WANS. It dynamically
> >> negetioates UDP sockets with portmap - if the negetiate fails, it runs
> >> badely and takes an age to connect.
> >>
> >> Point 2 is TESTS !!!! Write a "copy to server copy back to host file
> >> compare" script and run it for days. Typically this will move a few
> >> hundred MB from point A to B then back to A - when it arrives back at A
> >> compare the file with the original.
> >>
> >> Jon
> >
>
> > First NFS is not UDP based, it runs over either TCP or UDP.
>
> A quote from suns NFS description
>
> NFS originated from Sun Microsystems. The details of Sun RPC Version 2 can
> be found in RFC 1057 and consists of two flavors. The first is built using
> the sockets API and works with TCP or UDP. The other, transport
> independent (TI- RPC), is built using the TLI API and works with any
> transport layer. The most popular RPC implementation today is built using
> the sockets API with UDP.

Perhaps, but since we're talking about linux here perhaps the linux man
page would be more applicable:

...
tcp Mount the NFS filesystem using the TCP pro*
tocol instead of the default UDP protocol.
Many NFS severs only support UDP.
udp Mount the NFS filesystem using the UDP pro*
tocol. This is the default.
...