Hello Greg et al, Please consider adding the following commit to the 3.4 stable tree. One of the companies I work with has been hitting hash collisions with ext3 on their NFS servers. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;bug=685407 which describes the problem this fixes in more detail. Cheers, -ben commit d7dab39b6e16d5eea78ed3c705d2a2d0772b4f06 Author: Eric Sandeen <sandeen@xxxxxxxxxx> Date: Thu Apr 26 13:10:39 2012 -0500 ext3: return 32/64-bit dir name hash according to usage type This is based on commit d1f5273e9adb40724a85272f248f210dc4ce919a ext4: return 32/64-bit dir name hash according to usage type by Fan Yong <yong.fan@xxxxxxxxxxxxx> Traditionally ext2/3/4 has returned a 32-bit hash value from llseek() to appease NFSv2, which can only handle a 32-bit cookie for seekdir() and telldir(). However, this causes problems if there are 32-bit hash collisions, since the NFSv2 server can get stuck resending the same entries from the directory repeatedly. Allow ext3 to return a full 64-bit hash (both major and minor) for telldir to decrease the chance of hash collisions. This patch does implement a new ext3_dir_llseek op, because with 64-bit hashes, nfs will attempt to seek to a hash "offset" which is much larger than ext3's s_maxbytes. So for dx dirs, we call generic_file_llseek_size() with the appropriate max hash value as the maximum seekable size. Otherwise we just pass through to generic_file_llseek(). Patch-updated-by: Bernd Schubert <bernd.schubert@xxxxxxxxxxxxxxxxxx> Patch-updated-by: Eric Sandeen <sandeen@xxxxxxxxxx> (blame us if something is not correct) Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> Signed-off-by: Jan Kara <jack@xxxxxxx> -- "Thought is the essence of where you are now." -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html