On Thu, Mar 1, 2012 at 8:57 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> As long as full_name_hash() is still around, any such filesystem is welcome
> to use it for ->d_hash() and STFU.
Well, I'd make full_name_hash() match the new hash model, so no, they
couldn't use that. They'd have to actually implement the old hash, and
make it "their hash".
Also note that the hash model would have to become dependent on config
options: doing things a word at a time really only works well on
architectures that have fast unaligned accesses, and even on those
archtiectures it really doesn't work if you enable
CONFIG_DEBUG_PAGE_ALLOC.
> Note that there are places like this one (in btrfs_real_readdir())
> q.name = name_ptr;
> q.len = name_len;
> q.hash = full_name_hash(q.name, q.len);
> tmp = d_lookup(filp->f_dentry, &q);
> and they _will_ need to be updated if we switch the default.
I don't agree that it will need to be updated - I was planning on just
updating full_name_hash() to always match. That part is easy and
obvious.
So this I don't have any issue with. It's only if you actually save
the default VFS hash to disk (or network), since it will change
between reboots or between different machines.
> I'd be more
> worried about that kind of breakage, TBH, than anything leaking hash
> on disk without bothering to calculate it manually (if nothing else,
> finn_name_hash() is not endian-neutral, so any such place is buggy for
> another reason already).
No, full_name_hash() is perfectly endian-safe - currently. It does
everything one character at a time, and it acts as if it was all done
in 32 bits (even if it internally looks like it is calculating hashes
in "unsigned long" - the math is all stable in 32 bits and at the end
it is truncated down).
Now, of course, any disk respresentation would have to store the value
in some particular endianness, but that's no different from any other
number that FS would store.
But if I actually go ahead and do a word-at-a-time hash thing, that
hash value really fundamentally will depend on endianness. But since
it will depend on config options and on architecture details too,
that's the least of the problems with using that for anything
"stable". The new hash would literally only be useful *inside* the
kernel, and really only for looking up names on the hash lists.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
