SUMMARY: nfs behavior

From: Diane Ibaraki <diane_at_uhhepj.phys.hawaii.edu>
Date: Wed, 6 Dec 1995 11:55:30 -1000 (HST)

My original mail message is at end:

Thank you all for taking the time to respond:
Julie Battle <jab_at_ftp.pgh.wec.com>
alan_at_nabeth.cxo.dec.com
Larry Griffith <larry_at_liz.wsc.mass.edu>
Oyanarte Portilho <portilho_at_fis.unb.br>
Eric Bennett <bennett_at_hpel.umd.edu>
Dave Roberts <djr_at_saa-cons.co.uk>
Ken Teh <teh_at_chinook.phy.anl.gov>
Tom Barkanic <intrepid!tb_at_uunet.uu.net>
Sean Watson <swatson_at_ultrix6.cs.csubak.edu>

        The consensus was that I should have bg (background) in my fstab
file for nfs entries. I do have bg on all my nfs entries, rw,bg,intr 0 0.
I'm told the default would be hard if hard or soft is not specified.
Therefore, I believe I was impatient and booted the last nfs server
too quickly. Oyanarte says it takes about 2 - 3 minutes during which
time the "RPC: Timed out" message would have been displayed about 4 -5 times.
        Sean put together a nice summary/explanation of mnt_options:

fg (default):
  * when trying to mount, keep trying and don't let mount exit until you've
     succeeded
  * Use this for "critical" file systems that you're sure you can't live
     without
bg:
  * Try to mount once in the foreground. If it fails, keep trying in the
     background.
  * Use this for file systems you don't think are as important (extra
     disk space, etc).
  * It is a good idea to make dummy data that will be mounted over. For
     instance if you have a WWW file area mounted, you might want to put
     a file that says "Due to technical difficulty, the server's data is
     not available" as your default page before you mount the real
     WWW file area (so when it is not mounted people trying to to access
     files in the area will know what is happening). A less dramatic
     approach would be to at least make a file in each mount point's directory
     called "NFS_SERVER_DOWN".
hard,intr (default):
  * keep retrying (hang the process) until the NFS server responds or you
    get a signal
  * Use this on rw mounts

hard,nointr:
  * keep retrying (hang the process) until the NFS server responds (when even
    kill -KILL won't interrupt the read/write/etc request).
  * Use this for rw mounts where data written is critical

soft:
  * return an error to read(2)/write(2)/whatever when the NFS server times out
  * Use this for ro mounts where reads aren't critical.

      
----------------------- original email --------------------------
> I have a bunch of DUNIX systems of which three are nfs servers.
>I have set them up such that when a non-critical system crashes (serving
>data disk as opposed to mail, user home directory and /usr/local), the
others
>continue without hanging. Yesterday, we had a power outage. When I
>booted my nfs servers, they all booted until they got to the NFS part.
>They all stalled until the last of my three servers started up NFS and then
>they all booted up together. The messages on the waiting systems were:
> NFS Portmap: RPC: Portmapper failure - RPC: Timed out
>
> Is this how it is suppose to work? If one of my non-critical
>nfs servers could not be booted for what ever reason, would I have to
>change the fstab files prior to booting the other nfs servers? Or is
>there a way around this behavior?
>
>DUNIX versions of my nfs servers:
>2 systems at V3.2 214
>1 system at v2.0 240
>
Received on Wed Dec 06 1995 - 23:31:50 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:46 NZDT