Messages in this thread | | | Date | Tue, 11 Jun 2002 09:28:41 -0700 | From | Simon Matthews <> | Subject | Re: NFS Client mis-behaviour? |
| |
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/
| |