NFS stale file handles
Jim Gottlieb
It says that to get rid of stale NFS file handles, one must umount and
re-mount the partitions involved. Yes, this works.
Is there any other way? It's hard for me to believe that large sites
with hundreds of client workstations have to knock everyone off
(because otherwise the device is busy) and umount and mount all the NFS
mounts if a fileserver happens to crash or need rebooting.
Does the automounter help? I would guess not, because if the device is
"busy", then it would not be unmounted.
--
Jim Gottlieb
E-Mail: ji...@denwa.info.com In Japan: ji...@denwa.linc.or.jp
V-Mail: +1 310 551 7702 Fax: 478-3060 Voice: 824-5454
Kenneth H. Simpson
The server crashing or rebooting the server doesn't cause stale NFS handles.
--
==============================================================================
Kenneth Simpson NASA
Internet: k...@poincare.arc.nasa.gov Ames Research Center, MS/269-1
UUCP: ames!poincare!ken Moffett Field, CA 94035-1000
Peter G. Ford
>to get rid of stale NFS file handles, one must umount and re-mount the
>partitions involved. Yes, this works. Is there any other way? It's
>hard for me to believe that large sites with hundreds of client
>workstations have to knock everyone off (because otherwise the device
>is busy) and umount and mount all the NFS mounts if a fileserver
>happens to crash or need rebooting.
A "stale NFS handle" refers to a non-dismountable file system that has
been re-initialized while it is remotely mounted. Merely rebooting a
fileserver (or swapping a mountable disk or CD-ROM) shouldn't result
in a stale handle. Only re-formatting the disk partition, re-running
mkfs(8) or newfs(8), or renaming the mount point will make the handle
stale for remote hosts.
Peter Ford
<p...@space.mit.edu>
Guy Harris
>been re-initialized while it is remotely mounted. Merely rebooting a
>fileserver (or swapping a mountable disk or CD-ROM) shouldn't result
>in a stale handle.
Actually, if by "swapping a ... CD-ROM" you mean unmounting and
removing one CD-ROM and plugging in and mounting another, it *does*
result in a stale file handle, if the CD-ROM is a High Sierra or ISO
9660 CD-ROM, at least under SunOS 4.1[.x].
The decision to make it do so was deliberate; the comment in the code
reads:
/*
* We are now committed to the new filesystem.
*
* Find a unique filesystem id.
* Use creation date, but be prepared in case it is not unique
* (e.g., creation date could be 0 or -1 if conversion error).
*
* If creation date is used, this gives some chance of integrity
* across disk change. That is, if a client has an fhandle, it
* will be valid as long as the same disk is mounted.
*
* If all else fails, use a unique value which will guarantee
* that client fhandles go stale if the server crashes.
*/
so the idea was, presumably, not to surprise some NFS client that
expects the file system to be the same as it was when it mounted the
file system from the server.
This will, as indicated, cause file handles to go stale across a reboot
if it couldn't get the creation date from the HSFS/ISO 9660 header; if
it could get the creation date from there, though, a reboot shouldn't
cause file handles to go stale - assuming, of course, that the CD-ROM is
remounted on the reboot, which it might well not be!
Swapping a disk (or CD-ROM) with a UFS file system could cause stale
file handles as well, even for the root directory, as the "generation
count" (a value maintained on UFS inodes, at least, by most if not all
systems that do NFS, to ensure that a file handle for a file that's been
deleted won't be considered valid if some new file gets assigned the
same inode number as the old file) for the two root inodes may be
different.
>Only re-formatting the disk partition, re-running
>mkfs(8) or newfs(8), or renaming the mount point will make the handle
>stale for remote hosts.
Even "renaming the mount point" shouldn't do that, I think, as that
shouldn't change the mount point's file handle.
Changing the major/minor device number of the device on which the file
system resides (e.g., unplugging the device from a SCSI bus, changing
its SCSI ID, and plugging it back in) will change the file handle.
You might want to change "will" to "should", though; the implementor of
an OS might well screw up and arrange that file handles *not* persist
across reboots.
Larry Beaulieu
> A "stale NFS handle" refers to a non-dismountable file system that has
> been re-initialized while it is remotely mounted. Merely rebooting a
> fileserver (or swapping a mountable disk or CD-ROM) shouldn't result
> in a stale handle. Only re-formatting the disk partition, re-running
Unfortunately, a 4.1.x client using Sun's automounter CAN
have this happen if a server has been down long enough, even
if the NFS file systems were untouched. (I've seen it happen - more
than once :-(.
Fortunately, the AMD automounter doesn't exhibit this behavior.
--
--
Larry Beaulieu beau...@bose.com
Bose Corporation Phone: 508-879-1916 x6479
Framingham, MA 01701-9168 FAX: 508-820-4865
All flames gleefully ignored.
James O Ausman
Larry Beaulieu <beau...@bose.com> wrote:
>
>> A "stale NFS handle" refers to a non-dismountable file system that has
>> been re-initialized while it is remotely mounted. Merely rebooting a
>> fileserver (or swapping a mountable disk or CD-ROM) shouldn't result
>> in a stale handle. Only re-formatting the disk partition, re-running
>
> Unfortunately, a 4.1.x client using Sun's automounter CAN
> have this happen if a server has been down long enough, even
> if the NFS file systems were untouched. (I've seen it happen - more
> than once :-(.
>
> Fortunately, the AMD automounter doesn't exhibit this behavior.
It is also easy to get this simply by having machines foo and bar mounting
machine blah's disks. If they are both in the same directory and then the
process on machine foo does a:
cd ..; rm -r dir
and then the process on bar does anything in that (now nonexistent) directory,
you will get a "stale NFS handle" result. Of course, this is probably more an
argument against mounting multi-user disks NFS read/write, but still, it h
happens quite often here.
--
Jim Ausman
System Administrator
Center for Extreme Ultraviolet Astrophysics
Dave Hitz
>In article <2gl01j$k...@denwa.info.com> ji...@denwa.info.com (Jim Gottlieb) writes:
>>It says that
>>to get rid of stale NFS file handles, one must umount and re-mount the
>>partitions involved. Yes, this works. Is there any other way?
>A "stale NFS handle" refers to a non-dismountable file system that has
>been re-initialized while it is remotely mounted. Merely rebooting a
>fileserver (or swapping a mountable disk or CD-ROM) shouldn't result
>in a stale handle. Only re-formatting the disk partition, re-running
>mkfs(8) or newfs(8), or renaming the mount point will make the handle
>stale for remote hosts.
I think that rm(1) is a much more common source of stale file handles
than mkfs(8) or newfs(8).
A stale file handle is simply a file handle that points at a file that
no longer exists on the server. This commonly happens because a user
on one NFS client removes a file that a user on another client is in
the middle of using. If both users are on the same NFS client, then
the client moves the file to ".nfsXXX" instead of removing it, and the
stale file handle problem doesn't occur. When the remove is from a
different client, or from the server, then there is no way to detect
what is happening and do the move, and that's when the stale file
handle occurs.
Neither remounting nor rebooting fix the fundamental problem, which is
that a file you want is gone. Of course, a reboot does have the side
effect of blowing away any processes that were complaining, so it makes
the ESTALE messages go away. On the other hand, if the process
restarts and tries to access the file again, it'll just get ENOENT
instead of ESTALE. Not much of an improvement! You'd get the same
result from just killing that process manually.
I would suggest just killing any process that is trying to access a
stale file handle. If the stale file handle is stuck in the client's
attribute cache, you can flush it by running a find on a local file
system. (A clever client would throw away a cached inode that reported
ESTALE, but maybe some clients don't.)
I'm not saying that rebooting or remounting are *bad* things to do.
It's just that I usually find it easier to just stop using whatever
file seems to be reporting ESTALE.
Dave Hitz hi...@netapp.com
Network Appliance Corporation (415) 428-5106
Wasim Mohammad
Please help!
One of our network user has a sun3 machine which is using an automounted filesystem
and is exported from a sparc-2 machine. The user's sun3 machine is using SunOS 4.0.3
and the sparc-2 is using SunOS 4.1.3.
The problem is that when he finishes his 'ci' (Checking In) of files under /usr/opti/RCS/whatever/* (/usr/opti/RCS is an automounted filesystem) and then
does an "ls -l /usr/opti/RCS/whatever/file*" he gets an error which says "stale NFS file handle on file.c ", surprisingly when he repeats the same command "ls -l
/usr/opti/RCS/whatever/file*" this time he does not get any error message and the command executes successfully.
Whatever little knowledge I had to solve this problem I implemented them, like unmounting the filesystem, rebooting the machine, but nothing worked.
I will be greatful if anybody could suggest me any solution for the problem.
thanx in advance,