xfs
[Top] [All Lists]

Re: 2.6.xx: NFS: directory motion/cam2 contains a readdir loop

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: 2.6.xx: NFS: directory motion/cam2 contains a readdir loop
From: Rüdiger Meier <sweet_f_a@xxxxxx>
Date: Wed, 27 Jul 2011 22:26:55 +0200
Cc: Bryan Schumaker <bjschuma@xxxxxxxxxx>, Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>, "J. Bruce Fields" <bfields@xxxxxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <20110727200240.GA16054@xxxxxxxxxxxxx>
References: <alpine.DEB.2.02.1107270952270.1451@xxxxxxxxxxxxxxxx> <4E306D09.5030704@xxxxxxxxxx> <20110727200240.GA16054@xxxxxxxxxxxxx>
User-agent: KMail/1.9.10
On Wednesday 27 July 2011, Christoph Hellwig wrote:
> On Wed, Jul 27, 2011 at 03:54:49PM -0400, Bryan Schumaker wrote:
> > It should be printing on the second hit of a cookie.
>
> But looking closer at it it only prints the directory name and not
> that of any of the matching cookies, making it pretty useless to
> debug any problem.  (and it makes my previous question to Justin look
> stupid..).
>
>
> But so far I still stick to my previous theory that this sounds like
> a directory offset getting reused.  How is cache invalidation for
> the array supposed to work?  And maybe more importantly, given that
> he can only reproduce it with a .38 client did any bugs get fixed in
> that code recently that might lead to issues with the cache
> invalidation?

At the time I've started this thread
http://comments.gmane.org/gmane.linux.nfs/40863
I had the feeling that the readdir cache changings in 2.6.37 have 
something to do with these loop problems.

After that thread I've accepted that's a general problem with 
ext4/dirindex and nfs but seeing it again on xfs with just 5000 files 
I'm in doubt again.

cu,
Rudi

<Prev in Thread] Current Thread [Next in Thread>