* nfsv4 + readdir == too many requests
@ 2011-01-13 20:26 Tigran Mkrtchyan
2011-01-13 21:01 ` Trond Myklebust
0 siblings, 1 reply; 4+ messages in thread
From: Tigran Mkrtchyan @ 2011-01-13 20:26 UTC (permalink / raw)
To: NFS list
By running intensive tests I notice that readdir oration over nfsv4.1
asks for
file attributes in readdir (attr_request) and later on for each file. To
me it looks like
broken.
This 2.6.37 + pnfs-all-latests :
git://linux-nfs.org/~bhalevy/linux-pnfs.git
378978453b64bf895de8cd0e68dbcd9e9c0155ce
100% reproducible.
Regards,
Tigran.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nfsv4 + readdir == too many requests
2011-01-13 20:26 nfsv4 + readdir == too many requests Tigran Mkrtchyan
@ 2011-01-13 21:01 ` Trond Myklebust
2011-01-13 21:14 ` Tigran Mkrtchyan
0 siblings, 1 reply; 4+ messages in thread
From: Trond Myklebust @ 2011-01-13 21:01 UTC (permalink / raw)
To: Tigran Mkrtchyan; +Cc: NFS list
On Thu, 2011-01-13 at 21:26 +0100, Tigran Mkrtchyan wrote:
>
> By running intensive tests I notice that readdir oration over nfsv4.1
> asks for
> file attributes in readdir (attr_request) and later on for each file. To
> me it looks like
> broken.
>
> This 2.6.37 + pnfs-all-latests :
>
> git://linux-nfs.org/~bhalevy/linux-pnfs.git
> 378978453b64bf895de8cd0e68dbcd9e9c0155ce
>
> 100% reproducible.
1) What makes you think this is broken, and not just a case of the
attribute cache timing out and/or the directory changing?
2) Can you produce a testcase that proves brokenness?
3) Can you reproduce on a non-pnfs-all-latests kernel?
Readdir shouldn't be affected by the stuff in Benny's tree, but I'm
always wary of tests on out-of-mainline trees.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nfsv4 + readdir == too many requests
2011-01-13 21:01 ` Trond Myklebust
@ 2011-01-13 21:14 ` Tigran Mkrtchyan
2011-01-17 15:39 ` Tigran Mkrtchyan
0 siblings, 1 reply; 4+ messages in thread
From: Tigran Mkrtchyan @ 2011-01-13 21:14 UTC (permalink / raw)
To: NFS list; +Cc: Trond Myklebust
On 01/13/2011 10:01 PM, Trond Myklebust wrote:
> On Thu, 2011-01-13 at 21:26 +0100, Tigran Mkrtchyan wrote:
>
>> By running intensive tests I notice that readdir oration over nfsv4.1
>> asks for
>> file attributes in readdir (attr_request) and later on for each file. To
>> me it looks like
>> broken.
>>
>> This 2.6.37 + pnfs-all-latests :
>>
>> git://linux-nfs.org/~bhalevy/linux-pnfs.git
>> 378978453b64bf895de8cd0e68dbcd9e9c0155ce
>>
>> 100% reproducible.
>>
> 1) What makes you think this is broken, and not just a case of the
> attribute cache timing out and/or the directory changing?
>
The directory does not changed. I issue 'ls -l' and with wireshak can
see READDIR requests
followed by GETATTR. looks like cache is ignored or too small.
> 2) Can you produce a testcase that proves brokenness?
>
I will try to come up with something.
> 3) Can you reproduce on a non-pnfs-all-latests kernel?
>
> Readdir shouldn't be affected by the stuff in Benny's tree, but I'm
> always wary of tests on out-of-mainline trees.
>
NP. with vanilla 2.6.37 ?
Regards,
Tigran.
> Cheers
> Trond
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nfsv4 + readdir == too many requests
2011-01-13 21:14 ` Tigran Mkrtchyan
@ 2011-01-17 15:39 ` Tigran Mkrtchyan
0 siblings, 0 replies; 4+ messages in thread
From: Tigran Mkrtchyan @ 2011-01-17 15:39 UTC (permalink / raw)
To: NFS list; +Cc: Trond Myklebust
Still didn't got a time to test with vanilla kernel. But got some details.
It's works as expected with sec=sys. With sec=krb5 I see this effect.
Unfortunately kernel crashes as soon as I try to re-run tests. It simply
freezes with no stack traces....
Regards,
Tigran
On 01/13/2011 10:14 PM, Tigran Mkrtchyan wrote:
> On 01/13/2011 10:01 PM, Trond Myklebust wrote:
>> On Thu, 2011-01-13 at 21:26 +0100, Tigran Mkrtchyan wrote:
>>
>>> By running intensive tests I notice that readdir oration over nfsv4.1
>>> asks for
>>> file attributes in readdir (attr_request) and later on for each file. To
>>> me it looks like
>>> broken.
>>>
>>> This 2.6.37 + pnfs-all-latests :
>>>
>>> git://linux-nfs.org/~bhalevy/linux-pnfs.git
>>> 378978453b64bf895de8cd0e68dbcd9e9c0155ce
>>>
>>> 100% reproducible.
>>>
>> 1) What makes you think this is broken, and not just a case of the
>> attribute cache timing out and/or the directory changing?
>>
> The directory does not changed. I issue 'ls -l' and with wireshak can
> see READDIR requests
> followed by GETATTR. looks like cache is ignored or too small.
>> 2) Can you produce a testcase that proves brokenness?
>>
> I will try to come up with something.
>> 3) Can you reproduce on a non-pnfs-all-latests kernel?
>>
>> Readdir shouldn't be affected by the stuff in Benny's tree, but I'm
>> always wary of tests on out-of-mainline trees.
>>
> NP. with vanilla 2.6.37 ?
>
> Regards,
> Tigran.
>> Cheers
>> Trond
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-01-17 15:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-13 20:26 nfsv4 + readdir == too many requests Tigran Mkrtchyan
2011-01-13 21:01 ` Trond Myklebust
2011-01-13 21:14 ` Tigran Mkrtchyan
2011-01-17 15:39 ` Tigran Mkrtchyan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).