From: Txema Heredia Genestar <txema.heredia@upf.edu>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: NFSv4 memory allocation bug?
Date: Thu, 13 Jan 2011 16:48:26 +0100 [thread overview]
Message-ID: <4D2F1ECA.50703@upf.edu> (raw)
In-Reply-To: <20110112183557.GB11718@fieldses.org>
Hi Bruce, thanks for your answer
El 12/01/11 19:35, J. Bruce Fields escribió:
> On Wed, Jan 12, 2011 at 06:14:53PM +0100, Txema Heredia Genestar wrote:
>> Additionally, I have checked tcpdump and found, when mounting an
>> NFS4 drive from a working storage-system:
>> ...
>> 12:38:06.372303 IP client.907> storage.nfs: . ack 29 win 46
>> <nop,nop,timestamp 4063464822 174132214>
>> 12:38:06.372429 IP client.2364980656> storage.nfs: 148 getattr [|nfs]
>> 12:38:06.372792 IP storage.nfs> client.2364980656: reply ok 248
>> getattr [|nfs]
>> 12:38:06.372958 IP client.2381757872> storage.nfs: 172 getattr [|nfs]
>> 12:38:06.373132 IP storage.nfs> client.2381757872: reply ok 88
>> getattr [|nfs]
>> 12:38:06.373157 IP client.2398535088> storage.nfs: 176 getattr [|nfs]
>> 12:38:06.373316 IP storage.nfs> client.2398535088: reply ok 100
>> getattr [|nfs]
>> 12:38:06.373339 IP client.2415312304> storage.nfs: 172 getattr [|nfs]
>>
>>
>> But when I mount from the same client, the NFS4 share from my server
>> gets stuck on the "getattr" call
>> ...
>> 12:36:37.051840 IP client.926> server.nfs: . ack 29 win 140
>> <nop,nop,timestamp 4063375488 434039929>
>> 12:36:37.051903 IP client.1734362088> server.nfs: 148 getattr [|nfs]
>> 12:36:37.090274 IP server.nfs> client.926: . ack 192 win 4742
>> <nop,nop,timestamp 434039939 4063375488>
>> ---silence---
> Something like wireshark would give a few more details.
I have wiresharked it and I don't see any differences between the
"getattr" packages in both cases. Do you want me to paste them in a
specific format?
>> So I suppose that the "RPC: TCP recvfrom got EAGAIN" on the messages
>> log corresponds to that "getattr[|nfs]" call.
>>
>> I have been searching around and I have found several threads about
>> either the "malloc failure" message or the "EAGAIN" message. But I
>> haven't found anything concerning them both at the same time. I have
>> also checked for this kind of problems in NFS4 and found nothing
>> useful.
>>
>> May this be some kind of (already solved) bug in my nfs
>> implementation? I'm running a pretty old version (SuSE LES 10.2,
>> nfs-utils 1.0.7-36.2)
> What kernel version does that correspond to?
>
> My first impulse would be to make sure rpc.idmapd is running. (If not,
> the server would do an upcall to idmapd and never get a response, hence
> fail to respond to a client getattr.)
>
> --b.
My server kernel is 2.6.16.60-0.39.3
# uname -a
Linux bhsrv2 2.6.16.60-0.39.3-smp #1 SMP Mon May 11 11:46:34 UTC 2009
x86_64 x86_64 x86_64 GNU/Linux
I'm positive idmapd is running in both, server and client:
server
# ps -ef | grep idmap
root 11254 1 0 Jan12 ? 00:00:00 /usr/sbin/rpc.idmapd
client
# ps -ef | grep idmap
root 3262 1 0 2010 ? 00:00:02 rpc.idmapd
but it doesn't appear in rpcinfo -p, should it?
server
# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100024 1 udp 2526 status
100021 1 udp 2526 nlockmgr
100021 3 udp 2526 nlockmgr
100021 4 udp 2526 nlockmgr
100024 1 tcp 5726 status
100021 1 tcp 5726 nlockmgr
100021 3 tcp 5726 nlockmgr
100021 4 tcp 5726 nlockmgr
100005 1 udp 980 mountd
100005 1 tcp 980 mountd
100005 2 udp 980 mountd
100005 2 tcp 980 mountd
100005 3 udp 980 mountd
100005 3 tcp 980 mountd
1073741824 1 tcp 13587
and client:
# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 850 status
100024 1 tcp 853 status
100021 1 tcp 42074 nlockmgr
100021 3 tcp 42074 nlockmgr
100021 4 tcp 42074 nlockmgr
100021 1 udp 45871 nlockmgr
100021 3 udp 45871 nlockmgr
100021 4 udp 45871 nlockmgr
1073741824 1 tcp 57121
Thanks for any insight,
Txema
next prev parent reply other threads:[~2011-01-13 15:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-12 17:14 NFSv4 memory allocation bug? Txema Heredia Genestar
2011-01-12 18:35 ` J. Bruce Fields
2011-01-13 15:48 ` Txema Heredia Genestar [this message]
2011-01-13 16:19 ` J. Bruce Fields
2011-01-13 17:25 ` Txema Heredia Genestar
2011-01-13 18:05 ` J. Bruce Fields
2011-01-14 12:11 ` Txema Heredia Genestar
2011-02-08 18:07 ` Txema Heredia
2011-02-09 0:09 ` 'J. Bruce Fields'
2011-02-09 13:57 ` Txema Heredia Genestar
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=4D2F1ECA.50703@upf.edu \
--to=txema.heredia@upf.edu \
--cc=bfields@fieldses.org \
--cc=linux-nfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.