06effdbb49af5f6c "nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)" and previous patches solved problems with hash collisions in large directories by using 64- instead of 32- bit directory hashes in some cases. But it caused problems for users who assume directory offsets are "small". Two cases we've run across: - older NFS clients: 64-bit cookies cause applications on many older clients to fail. - gluster: gluster assumed that it could take the top bits of the offset for its own use. In both cases we could argue we're in the right: the nfs protocol defines cookies to be 64 bits, so clients should be prepared to handle them (remapping to smaller integers if necessary to placate applications using older system interfaces). And gluster was incorrect to assume that the "offset" was really an "offset" as opposed to just an opaque value. But in practice things that worked fine for a long time break on a kernel upgrade. So at a minimum I think we owe people a workaround, and turning off dir_index may not be practical for everyone. A "no_64bit_cookies" export option would provide a workaround for NFS servers with older NFS clients, but not for applications like gluster. For that reason I'd rather have a way to turn this off on a given ext4 filesystem. Is that practical? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
