public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* NFS long wait problem
@ 2001-11-28 13:56 kernel
  2001-11-28 14:14 ` Trond Myklebust
  0 siblings, 1 reply; 2+ messages in thread
From: kernel @ 2001-11-28 13:56 UTC (permalink / raw)
  To: linux-kernel

Hi,
  I have a problem with my home network. I have a client PC which mounts
/home as an NFS share on the server. Once in a while, all access to the
mounted directory is stalled and the following data is transferred on the
network:

06:45:23.270071 192.168.1.2.1402759134 > 192.168.1.1.2049: 100 null (DF)
06:45:23.271049 192.168.1.1.2049 > 192.168.1.2.1402759134: reply ok 24 null (DF)
06:45:23.271105 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @ 0x04019e000 (DF)
06:45:24.670061 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @ 0x04019e000 (DF)
06:45:27.470062 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @ 0x04019e000 (DF)
06:45:33.070065 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @ 0x04019e000 (DF)
06:45:44.270083 192.168.1.2.1419536350 > 192.168.1.1.2049: 100 null (DF)
06:45:44.270563 192.168.1.1.2049 > 192.168.1.2.1419536350: reply ok 24 null (DF)
06:45:44.270619 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @ 0x04019e000 (DF)
06:45:47.070068 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @ 0x04019e000 (DF)
06:45:52.670060 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @ 0x04019e000 (DF)
06:46:03.870068 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @ 0x04019e000 (DF)
06:46:04.115689 192.168.1.1.2049 > 192.168.1.2.1302095838: reply ok 136 write [|nfs] (DF)

  This cannot be a physical link problem, as other packets get transferred
correctly on the same link. When this happens, it's always with NFS V3 WRITE
calls. Any ideas?

  I'm running MDK8.1 (kernel 2.4.8-19mdk) on both the client and the server.

Thanks in advance,
  Alon

-- 
This message was sent by Alon Altman (Psycho99@bigfoot.com) ICQ:1366540
The RIGHT way to contact me is by e-mail. I am otherwise nonexistent :)
--------------------------------------------------------------------------
"jackpot:  you may have an unneccessary change record"
-- message from "diff"


=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il


-- 
This message was sent by Alon Altman (Psycho99@bigfoot.com) ICQ:1366540
The RIGHT way to contact me is by e-mail. I am otherwise nonexistent :)
--------------------------------------------------------------------------
You don't have to know how the computer works, just how to work the computer.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: NFS long wait problem
  2001-11-28 13:56 NFS long wait problem kernel
@ 2001-11-28 14:14 ` Trond Myklebust
  0 siblings, 0 replies; 2+ messages in thread
From: Trond Myklebust @ 2001-11-28 14:14 UTC (permalink / raw)
  To: kernel; +Cc: linux-kernel

>>>>> " " == kernel  <kernel@alon.wox.org> writes:

     > 06:45:23.270071 192.168.1.2.1402759134 > 192.168.1.1.2049: 100
     > null (DF) 06:45:23.271049 192.168.1.1.2049 >
     > 192.168.1.2.1402759134: reply ok 24 null (DF) 06:45:23.271105
     > 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh
     > 96,1/197709 960 bytes @ 0x04019e000 (DF) 06:45:24.670061
     > 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh
     > 96,1/197709 960 bytes @ 0x04019e000 (DF) 06:45:27.470062
     > 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh
     > 96,1/197709 960 bytes @ 0x04019e000 (DF) 06:45:33.070065
     > 192.168.1.2.1302095838 > 192.168.1.1.2049: 1100 write fh
     > 96,1/197709 960 bytes @ 0x04019e000 (DF) 06:45:44.270083
     > 192.168.1.2.1419536350 > 192.168.1.1.2049: 100 null (DF)
     > 06:45:44.270563 192.168.1.1.2049 > 192.168.1.2.1419536350:
     > reply ok 24 null (DF) 06:45:44.270619 192.168.1.2.1302095838 >
     > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @
     > 0x04019e000 (DF) 06:45:47.070068 192.168.1.2.1302095838 >
     > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @
     > 0x04019e000 (DF) 06:45:52.670060 192.168.1.2.1302095838 >
     > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @
     > 0x04019e000 (DF) 06:46:03.870068 192.168.1.2.1302095838 >
     > 192.168.1.1.2049: 1100 write fh 96,1/197709 960 bytes @
     > 0x04019e000 (DF) 06:46:04.115689 192.168.1.1.2049 >
     > 192.168.1.2.1302095838: reply ok 136 write [|nfs] (DF)

     >   This cannot be a physical link problem, as other packets get
     >   transferred
     > correctly on the same link. When this happens, it's always with
     > NFS V3 WRITE calls. Any ideas?

The client isn't seeing any replies from the server. Each and every
one of those write requests should normally be followed up with an
'OK' from the server.

Either the server isn't seeing the write requests, or it isn't
replying to them (because it is busy?) or they are getting lost
somewhere on your network on the way back to the client.

A comparison of 'tcpdump' on the client and the server will tell you
which of these 3 hypotheses is correct.

Cheers,
  Trond

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-11-28 14:16 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-11-28 13:56 NFS long wait problem kernel
2001-11-28 14:14 ` Trond Myklebust

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox