From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: <kernel@alon.wox.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: NFS long wait problem
Date: 28 Nov 2001 15:14:38 +0100 [thread overview]
Message-ID: <shsu1vfrnht.fsf@charged.uio.no> (raw)
In-Reply-To: <Pine.LNX.4.33L2.0111281553120.786-100000@alon1.dhs.org>
In-Reply-To: <Pine.LNX.4.33L2.0111281553120.786-100000@alon1.dhs.org>
>>>>> " " == 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
prev parent reply other threads:[~2001-11-28 14:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-28 13:56 NFS long wait problem kernel
2001-11-28 14:14 ` Trond Myklebust [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=shsu1vfrnht.fsf@charged.uio.no \
--to=trond.myklebust@fys.uio.no \
--cc=kernel@alon.wox.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox