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[1] produce a lot of
other nasty looking messages. In addition, sometimes programs
on my client NFS computer[2] 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
read-only filesystem!
NOTES:
[1] 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.
[2] Everything on this computer is NFS-root mounted, with the "nolock"
option.
Brian May <bam@snoopy.apana.org.au>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/