Re: infinite getdents64 loop

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux