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
