Trond,
I realize that the transport is hidden to NFS. However, in the situation I
described, the NFS client did not behave well: it seemed to lock up totally
for a period of 10-15 minutes.
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".
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.
Simon
At 04:31 PM 6/11/02 +0200, Trond Myklebust wrote:
> >>>>> " " == Simon Matthews <simon@paxonet.com> writes:
>
> > Solution: the Ethernet interface was connected to a switch that
> > only supports half-duplex connecting to a full-duplex switch
> > solved the problem. However, it does seem that the NFS client
> > was not handling the situation well.
>
>The NFS client neither knows nor cares what is going on down in the
>ethernet layer. As far as it is concerned, you might as well be using
>semaphore to pass messages between the computers.
>
>All the NFS client needs to know is that it should retry the socket
>sendmsg() operation when a certain (user defined) timeout value is
>reached.
>
>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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:23 EST