Re: [PATCH v1 5/10] ext4: Add DX_HASH_SIPHASH24 support

["George Spelvin" <linux@horizon.com>]

>>> Still, it would probably simpler to not try to assign
>>> DX_HASH_SIPHASH24 to be 6, and to leave better comments about how the
>>> hash values are used.
>> 
>> Is that "not try" supposed to be in there?
>
> Sorry, typo.  Yes, it would be better to assign DX_HASH_SIPHASH24 to
> be 6, and not to assign the code points 3, 4, and 5 just to be safe.

I thought so, I just wanted a retransmit rather than rely on FEC in this
case. :-)

Another option I thought of I'd like to get formally rejected would be
to consider all future hashes unsigned, so there's a +3 offset between
the on-disk value and the ext2fs_dirhash parameter.

That keeps the disk numbering clean and preserves the library ABI, but
(pick any two!) makes the source messier.  (Not as much as you might
think, because it just requires extening the current kludge, but still...)

> (I assume you're using tmpfs.)  There would be less overhead if you
> actually used a real ramdisk, i.e., /dev/ram0, which might reduce some
> of the variance and increase the percentage of the difference, but
> yeah, it's not that surprising that we're not seeing much difference.

Oops, forgot to say that.  Yes, tmpfs.  I didn't realize /dev/ram* had
less overhead; I'll try that.  Thanks!