bam at snoopy
Mar 25, 1999, 10:34 PM
Post #1 of 1
Unexpected NFS client errors if server dies.
If the NFS server dies, other Unix OS NFS clients simply continue
retrying until the server comes back alive again. ie you would
expect errors like the following:
nfs: server 192.168.87.129 not responding, still trying
nfs: server 192.168.87.129 OK
(that is what an Ultrix NFS-Root computer does. I have also seen
similar results on OSF/1.)
However, Linux 2.2.3 server and client combination produce a lot of
other nasty looking messages. In addition, sometimes programs
on my client NFS computer die: eg syslogd.
I have retyped them below; errors in my version may exist. Where these
were repeated, I have only entered the one version. Everything except
the bottom group of messages where frequently repeated. The bottom group
of messages appeared when the NFS server came back online.
RPC: task of released request still queued!
RPC: (task is on xprt_pending)
nfs: RPC call returned error 111
nfs: task 15508 can't get a request slot
__nfs_fhget: inode 1476520848 busy, i_count=2, i_nlink=1
nfs_free_dentries: found sbin/getty, d_count=4, hashed=0
__nfs_fhget: inode 1476520848 still busy, i_count=2
__nfs_fhget: killing sbin/getty filehandle
Any ideas?? I might assume that these messages are normal (are they?),
however, this shouldn't ever cause programs to die (within reason, of
course, ie ssh sessions might die for other reasons)... I have no idea
what is special about "sbin/getty" but it still seems to be working fine
on my NFS client...
Hmmm... Those messages seem to imply filelocking is in use. I wonder
if Linux is somehow ignoring the "nolock" option which appears
in the output of mount. Filelocking is not required - it is a
 I assume that hard mounts are the default for Linux - the output
of mount doesn't say, and I can't be bothered rerunning the check with
"hard" specificall specified. I will do so though if anyone thinks
"soft" might be the default.
 Everything on this computer is NFS-root mounted, with the "nolock"
Brian May <bam [at] snoopy>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
Please read the FAQ at http://www.tux.org/lkml/