Hi!
I received two more replies after sending this SUMMARY.
Thanx for the same - Its really easier,
--------------------------
#fuser -c -u /filesystem
This will return a list of processes on the filesystem that you are getting
Stale NFS errors from.
Kill all the processes; unmount the filesystem, and remount the filesystem.
Takes less than 2 minutes. :)
Turtle" <turtle@pinn.net>
-------------------------------
----- Begin Included Message -----
>From sridhar@blr.hl.siemens.de Tue Feb 16 19:25:07 1999
X-Envelope-Sender-Is: sridhar@blr.hl.siemens.de (at relayer david.siemens.de)
Date: Tue, 16 Feb 1999 17:43:36 GMT
From: Sridhar M <sridhar@blr.hl.siemens.de>
To: sun-managers@sunmanagers.ececs.uc.edu
Subject: SUMMARY: Stafe NFS File Handle.
Hi all!
Thanx to those who all responded.
Eric Lewandowski <eric@disco.cs.odu.edu>
Raghavendra. <RBHAT.IN.ORACLE.COM.ofcmail@in.oracle.com>
Richard Smith <rc.smith@ibm.net>
Grant Schoep <grant@storm.com>
T Karthikeyan <sun_ultra@hotmail.com>
My Orinal Question is below..
The answer:
Here is an abstract from sunsolve cd.
A1: This means that a file or directory that your client has open has
been removed or replaced on the server. It happens most often when a
dramatic change is made to the file system on the server, for example
if it was moved to a new disk or totally erased and restored. The
client should be rebooted to clear Stale NFS file handles.
A2: If you prefer not to reboot the machine, you can create a new
mount point on the client for the mount point with the Stale NFS file
handle.
Other than this you may try to get the fileinfo from the filehandle
and try
to
kill the process which have these files open.
Use following to get fileinfo from the file handle.
------------------------
#I'm now able to decode what those Stale NFS file handle:
#(file handle: 80000e 2 a0000 a2b40 6c32949a a0000 2 2fede13) mean.
#!/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 can take a long time.
# Since there's no way to terminate the find upon finding
# the file, you might need to kill fhfind after it prints
# the path.
#
if [ $# -ne 8 ]; then
echo
echo "Usage: fhfind <filehandle> e.g."
echo
echo " nfsfind 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
-----end cut------
Hi all!
While this topic seems to be more simple and often discussed, I am
facing a lot problems though.
The scenario goes this way..
We have E3000 as NIS & NFS Server, from whom all the clients mount their
home directories through automount(Including the software & licenses).
All the home have been "hard" mounted and others "soft".
Whenever I move/relocate few few home directories and partitions, and
after changing them in maps & updating them - the clients obviously say
"Stale NFS Handle".(Note: the directories are and shared )
SO, I tried restarting the "automount -v" daemon in the clients which
says "no mounts , no umou nts" - does nothing and comes back. I tried
stoping and restarting the /etc/rc2.d/*autofs, nfs.client scripts but in
vain.
While I understand that the "automount" automatically mounts when
required and umount when does not found any activity for default 5 mins
- which is not happening - probably users are in their home directories.
So when I try to umount their home/%username5 and home/%software%
directories I get "busy" and cannot umount them.
The only thing letf is to reboot the clients - which is really a pain
and not worth the efforts.
I feel I am missing somewhere.
Can anyone throw some light on this.
Thanx in Advance,
-------------------------
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:15 CDT