Hi ,
I would like to thank all those who replied to
the following query.
########################################################################
> From sun-managers-relay@ra.mcs.anl.gov Wed Jan 24 12:10 GMT 1996
> Sender: sun-managers-relay@ra.mcs.anl.gov
> Date: Tue, 23 Jan 1996 10:42:01 GMT
> From: jamesc@s3two.ie (James Cassidy)
> Reply-To: jamesc@s3two.ie (James Cassidy)
> Followup-To: junk
> To: sun-managers@ra.mcs.anl.gov
> Subject: Stale NFS file handles
> Cc: james@s3two.ie
> X-Sun-Charset: US-ASCII
> Content-Type: text
> Content-Length: 511
>
> Hi all,
>
> I have the following network configuration.
> An NIS+ Server (Sol 2.4) and a number if NIS clients (4.1.3_U1),
> as well as a few NIS+ clients.
>
> I seem to geting quite a number of Stale NFS errors on Sol 1 clients.
>
> example:
> --------
>
> NFS write error 70 on host xxxxx fh 710 1 a0000 90a00 3246c3a3 a0000 34db8 34b235b
>
> where xxxxx is an NIS client exporting NFS filesystems to a selection
> of Solaris 1 and Solaris 2 hosts.
>
> Could you shed any light on this issue.
>
>
> thanks in advance,
>
> James.
>
>
>
###########################################################################
Here are the respnoses I received.
###########################################################################
> From storm@kepler.uni-paderborn.de Wed Jan 24 20:52 GMT 1996
> From: Markus Storm <storm@math.uni-paderborn.de>
> Subject: Re: Stale NFS file handles
> To: jamesc@s3two.ie
> Date: Wed, 24 Jan 1996 21:54:20 +0100 (MET)
> X-Mailer: ELM [version 2.4 PL25 PGP2]
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
>
> >
> You can look up errnos in /usr/include/sys/ernno.h and use the following script to translate
> the file handle into a filename (run it on a Sol 2 Server).
>
> Markus
>
>
> ////////////////////////////////////////////////////////////////
> Markus Storm Univ. of Paderborn, Dept. of Maths
> storm@uni-paderborn.de SUN systems administration
> +49 (421) 60-2634 33095 Paderborn, Germany
>
>
>
> #!/bin/sh
> #
> # fhfind: takes the expanded filehandle string from an
> # NFS write error or stale filehandle message and maps
> # it to a pathname on the server.
> #
> # The device id in the filehandle is used to locate the
> # filesystem mountpoint. This is then used as the starting
> # point for a find for the file with the inode number
> # extracted from the filehandle.
> #
> # If the filesystem is big - the find may take a long time.
> # Since there's no way to terminate the find upon finding
> # the file, you may need to kill fhfind after it prints
> # the path.
> #
>
> if [ $# -ne 8 ]; then
> echo
> echo "Usage: fhfind <filehandle> e.g."
> echo
> echo " fhfind 1540002 2 a0000 4df07 48df4455 a0000 2 25d1121d"
> exit 1
> fi
>
> # Filesystem ID
>
> FSID1=$1
> FSID2=$2
>
> # FID for the file
>
> FFID1=$3
> FFID2=`echo $4 | tr "[a-z]" "[A-Z]"` # uppercase for bc
> FFID3=$5
>
> # FID for the export point (not used)
>
> EFID1=$6
> EFID2=$7
> EFID3=$8
>
> # Use the device id to find the /etc/mnttab
> # entry and thus the mountpoint for the filesystem.
>
> E=`grep $FSID1 /etc/mnttab`
> if [ "$E" = "" ] ; then
> echo
> echo "Cannot find filesystem for devid $FSID1"
> exit 0
> fi
>
> set - $E
> MNTPNT=$2
>
> INUM=`echo "ibase=16;$FFID2" | bc` # hex to decimal for find
> echo
> echo "Now searching $MNTPNT for inode number $INUM"
> echo
>
> find $MNTPNT -mount -inum $INUM -print 2>/dev/null
###################################################################################
>
> From kevin@more.com Wed Jan 24 23:50 GMT 1996
> From: kevin@somemore.more.com (Kevin Sheehan {Consulting Poster Child})
> Date: Wed, 24 Jan 1996 15:37:35 PST
> Reply-To: kevin@more.com
> X-Mailer: Mail User's Shell (7.1.2 7/11/90)
> To: jamesc@s3two.ie (James Cassidy)
> Subject: Re: Stale NFS file handles
> Content-Type: text
> Content-Length: 962
>
> [ Regarding "Stale NFS file handles", jamesc@s3two.ie writes on Jan 23: ]
> need more info - but basically, if the system has rebooted, or the
> file system has been unmounted/remounted or re-exported, then you
> can get stale handles.
>
> What it means is that the server now thinks it has been restarted since
> the file handle generating the error was created, and isn't sure that
> this is a valid handle anymore.
>
> l & h,
> kev
########################################################################################
>
> From and@morgan.com Wed Jan 24 11:35 GMT 1996
> X-Mailer: exmh version 1.6.4 10/10/95
> To: jamesc@s3two.ie (James Cassidy)
> Subject: Re: Stale NFS file handles
> X-Url: http://lndevd1.morgan.com/~and
> X-Face: =cP7su>gJcuSSc5q*e'k5nfzYs\:=k7s@Kw?RN)zjz_}C$SAZlFCU!&PwiXZ!>b#='D;uB/
> {5;Pm@EN(q%s5d,(DF<177&o`Qh#D.;KgoCOlt-bc5o%Hy+m<XOMh(5n-~[*[4kZM>Ms^nit\("v7{
> MaM6lbzlEB>c1d3Y[[wy'(k+Q`UFkP('Cbmt7T$C@TI3Z56JvJ8D1\fd>;b%Am7x:@aS!NF,}UTmQv
> V`@Vk;np/)c=dr79<PaP?7;~U\~zM;OThl2?/|'O~\BP7r%%[2m$#8
> Mime-Version: 1.0
> Date: Wed, 24 Jan 1996 11:35:29 +0000
> From: Anderson McCammont <and@morgan.com>
>
>
> from /usr/include/nfs/nfs.h
> > NFSERR_STALE = 70, /* Stale NFS file handle */
>
> has your server been going down, or many people writing to the same file
> coupled with high network load?
>
>
> --
> Andy McCammont PGP/MIME and@morgan.com
>
>
#########################################################################################
>
> From Rasana.Atreya@library.ucsf.edu Wed Jan 24 17:12 GMT 1996
> To: jamesc@s3two.ie (James Cassidy)
> Subject: Re: Stale NFS file handles
> Date: Wed, 24 Jan 1996 09:14:51 PST
> From: "Rasana P. Atreya" <Rasana.Atreya@library.ucsf.edu>
> Content-Type: text
> Content-Length: 812
>
> You might want to check if the server moved, or if the resources on the
> server got unshared.
>
> Rasana Atreya
>
##############################################################################
>
> From baldwinj@mailbox.ne.tpd.eds.com Thu Jan 25 16:31 GMT 1996
> Date: Thu, 25 Jan 1996 11:32:54 -0500
> From: baldwinj@mailbox.ne.tpd.eds.com (John Baldwin)
> To: jamesc@s3two.ie
> Subject: Re: Stale NFS file handles
> X-Sun-Charset: US-ASCII
> Content-Type: text
> Content-Length: 1335
>
>
> James,
>
> A file handle becomes stale whenever the directory or file represented by the handle is removed by one client while another client still has it open, or if the directory is reexported by the server. If your clients consistently suffer from stale nfs handles you need to look at the way you share NFS files, a good alternative would be to implement the automounter to make NFS client administration easier and more productive, and also if you are doing plenty of development work implement a souce code control system...
>
>
> john
>
#################################################################################
thanks to all who replied.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:52 CDT