Re: infinite getdents64 loop

From: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-nfs@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: infinite getdents64 loop
Date: Tue, 31 May 2011 12:18:11 +0200	[thread overview]
Message-ID: <4DE4C063.9060100@itwm.fraunhofer.de> (raw)
In-Reply-To: <201105311147.24939.sweet_f_a@gmx.de>

On 05/31/2011 11:47 AM, Rüdiger Meier wrote:
> On Monday 30 May 2011, Trond Myklebust wrote:
>> On Mon, 2011-05-30 at 11:37 +0200, Ruediger Meier wrote:
>>>
>>> Does this mean ext4 generally does not work with for nfs?
>>
>> ext2/3/4 are all known to have this problem when you switch on the
>> hashed b-tree directories. Typically, a directory with a million
>> entries will have several tens of cookie collisions.
>
> Ok, like Jeff mentioned in the other reply disabling dir_index solves
> it.
>
> I wish I had seen this documented somewhere before switching from xfs to
> ext4 but it's not easy to find something about these ext4/nfs probs
> without knowing the details already.
> Ext4 being default file system on many distros made me feel safe.

Well, this is hardly acceptable and we really need to find a solution. I 
think any parallel filesystem and fuse, etc will have problems with that.

Out of interest, did anyone ever benchmark if dirindex provides any 
advantages to readdir?  And did those benchmarks include the 
disadvantages of the present implementation (non-linear inode numbers 
from readdir, so disk seeks on stat() (e.g. from 'ls -l') or
'rm -fr $dir')?

I see those options to solve the ext3/ext4 seek problem:

1) Break 32bit applications on 64 bit kernels

2) Update the vfs to tell the underlying functions to tell them if 
lseek() was called from 64bit or 32bit userspace

3) Disable dirindexing for readdirs

Thanks,
Bernd

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html