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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Patch-updated-by: Eric Sandeen <[email protected]>
(blame us if something is not correct)
Signed-off-by: Eric Sandeen <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
--
"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
