Messages in this thread | | | From | Trond Myklebust <> | Subject | Re: NFS Client mis-behaviour? | Date | Wed, 12 Jun 2002 13:57:45 +0200 |
| |
On Tuesday 11 June 2002 18:28, Simon Matthews wrote:
> 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/
| |