NFS problem

[S. Johnson]

Hi Bob,

Good to hear from you!
At 09:39 10/02/03 -0700, you wrote:
>Well, first thing that I would do is change the mount options to add the 
>'soft'
>option:
>server3:/users /users nfs bg,soft,nfsvers=3,rsize=8192,wsize=8192 0 0

Referencing the sourceforge site, it says that soft mounting is a BAD thing if
you value your mail.  Here's a quote from the site:

  If a file request fails, the NFS client will report an error to the 
process on the client machine requesting the file access. Some programs can 
handle this with composure, most won't. We do not recommend using this 
setting; it is a recipe for corrupted files and lost data. You should 
especially not use this for mail disks --- if you value your mail, that is.

How will courier-imap and Postfix handle things if a request times out?  I 
would still take Bob's recommendation over that of a single reference on 
sourceforge.  I will do some testing using a soft mount and a hard mount 
with the intr option as well.


>If you don't want to do soft mount, then add the 'intr' parameter to make hard
>mounted nfs I/O interruptable.  This means that a hung process can be
>interrupted by a signal which causes the I/O call to return 'EINTR' to the
>calling process.
>
>I would start looking at your networking parameters in all three 
>systems.  This
>sounds like you might be on a 100baseT network and you're having connectivity
>problems.  On your switches, lock the ports that the servers are on to
>100BaseT-FD (100 Mbit, Full Duplex).  Then do the same on each machine 
>with the
>'mii-tool --force 100baseT-FD'.

This was another major concern of mine.  I would like to force the ports on 
the switch
to 100FD, but have seen bad problems if the device at the other end is not 
running at
100FD.  Having a way to force the card to 100FD will be a great.  Here's 
what the cards
are running at Eth1 is the interface NFS runs over.
[root at alpine3 /]# mii-tool -v
eth0: negotiated 100baseTx-FD, link ok
   product info: vendor 00:50:43, model 3 rev 0
   basic mode:   autonegotiation enabled
   basic status: autonegotiation complete, link ok
   capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
   advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
   link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
eth1: negotiated 100baseTx-FD, link ok
   product info: Intel 82555 rev 4
   basic mode:   autonegotiation enabled
   basic status: autonegotiation complete, link ok
   capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
   advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
   link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD

I will check the link status again while coping over some files.  I still 
have not
checked the link settings on the switch.  Would it be safe to force the 
link on
the switch to 100FD?  What about enabling flow-control?

Thanks again!

Sean Johnson


>Cheers!
>
>Bob




>--- "S. Johnson" <zatharus at ncn.net> wrote:
> > I have 2 client systems that need to access a mail volume via NFS.  I
> > believe it is an optimization/setup problem, but am unsure of what to try
> > to resolve it.  Here's the setup:
> >
> > Server 3 - NFS Server, redhat 8.0, exporting /users from a fiber channel
> > array it hosts.  Mail is sent to and picked up to users home directories,
> > so there is a lot of disk access happening with read and writes (4500
> > users).  /etc/exports looks like this:
> >
> > /db     192.168.1.0/255.255.255.0(rw,no_root_squash)
> > /isp    192.168.1.0/255.255.255.0(rw,no_root_squash)
> > /users  192.168.1.0/255.255.255.0(rw,no_root_squash)
> >
> > For now, the main export I am concerned with is /users, however, all these
> > partitions are on the same fiber channel raid and are still accessed by 
> the
> > clients.  Traffic on the other two shares in pretty minimal, but may still
> > be a factor in overall performance of the system.
> >
> > Servers 1 and 2 are configured to be able to run Postfix or courier-imap,
> > and access the /users share from server 3 via NFS.  Here is the /etc/fstab
> > the clients use:
> >
> > server3:/db    /db    nfs bg,nfsvers=3,rsize=8192,wsize=8192 0 0
> > server3:/isp   /isp   nfs bg,nfsvers=3,rsize=8192,wsize=8192 0 0
> > server3:/users /users nfs bg,nfsvers=3,rsize=8192,wsize=8192 0 0
> >
> > Servers 1 and 2 are able to mount and read the volumes fine when there is
> > little or no traffic.  However, when you move either Postfix or
> > Courier-imap services over to them, they eventually (after several hours)
> > start to have NFS problems.  After a while, there will be hundreds of dead
> > processes still hanging around and the load average skyrockets (200 or
> > more).  The mounts to /users or the other two are not 
> available.  Executing
> > a df or mount command hangs your terminal.  Sometimes you can kill off
> > processes and restart NFS services, other times it requires a reboot of 
> the
> > client and usually means doing it by powering off the machine because it
> > hangs on the NFS processes and will not shut them down.
> >
> > Is there a tried and true way to setup NFS between the server and clients
> > that will support high volumes of traffic?  If anyone knows of a better 
> way
> > to setup things the client and/or server side, please let me know.
> >
> > Thanks,
> >
> > Sean Johnson
> >
>
>
>__________________________________
>Do you Yahoo!?
>The New Yahoo! Shopping - with improved product search
>http://shopping.yahoo.com