[lkml]   [2002]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS Client mis-behaviour?
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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:26    [W:0.038 / U:5.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site