[Top] [All Lists]

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

To: R?diger Meier <sweet_f_a@xxxxxx>
Subject: Re: 2.6.xx: NFS: directory motion/cam2 contains a readdir loop
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed, 27 Jul 2011 16:47:24 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Bryan Schumaker <bjschuma@xxxxxxxxxx>, Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>, "J. Bruce Fields" <bfields@xxxxxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <201107272227.03265.sweet_f_a@xxxxxx>
References: <alpine.DEB.2.02.1107270952270.1451@xxxxxxxxxxxxxxxx> <4E306D09.5030704@xxxxxxxxxx> <20110727200240.GA16054@xxxxxxxxxxxxx> <201107272227.03265.sweet_f_a@xxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Jul 27, 2011 at 10:26:55PM +0200, R?diger Meier wrote:
> 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.

Two separate issues.  For one thing the nfs code simply doesn't seem
to handle changing directories very well, and one and a half the Linux
NFS server might even send incoherent readdir output in a single
protocol reply.

Issue two is that the ext3/4 hashed directory format is too simply (not
to say dumb) to provide a proper 32-bit linear value for the dirent
d_off field.  It's not a complex task, and the first relatively simple
generation of xfs btree directories couldn't handle it either.  The
v2 directory format handles it fine, but at the cost of a much more
complex codebase.

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