> Other packets were able to make it into and out of the machine: I could
> telnet/ssh/rlogin. The user could not interrupt the process, despite the
> fact that the mount options included "intr".
There is a well known problem with 'intr': if one process is waiting on the
page lock, then there is no provision for interrupting (that's a known
weakness with the MM layer).
Since taking the page lock is usually done by some process that wants to read
from a page, the usual cause of such a hangup is the fact that some other
process is in the middle of an NFS READ. For this reason, if you kill *all*
READ operations (by doing 'killall -9 rpciod) then you can usually recover.
That's something that is only possible for 'root' though...
> My point is that the use of half-duplex may prevent the NFS client from
> sending or receiving (probably sending) some packets. But, since the
> processes that caused the load had stopped doing anything and other packets
> were passing in and out, the NFS client should have been able to recover
> earlier.
As I said, all the client is required to do is to retry (unless it gets
interrupted). I'm not sure what else you mean by 'recover' in the above
sentence.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/