On 07/11/2012 03:39 PM, David Magda wrote:
> On Tue, July 10, 2012 19:56, Sašo Kiselkov wrote:
>> However, before I start out on a pointless endeavor, I wanted to probe
>> the field of ZFS users, especially those using dedup, on whether their
>> workloads would benefit from a faster hash algorithm (and hence, lower
>> CPU utilization). Developments of late have suggested to me three
>> possible candidates:
> [...]
> I'd wait until SHA-3 is announced. It's supposed to happen this year, of
> which only six months are left:
>     http://csrc.nist.gov/groups/ST/hash/timeline.html
>     http://en.wikipedia.org/wiki/NIST_hash_function_competition
> It was actually supposed to happen to "2Q", so they're running a little
> late it seems.

I'm not convinced waiting makes much sense. The SHA-3 standardization
process' goals are different from "ours". SHA-3 can choose to go with
something that's slower, but has a higher security margin. I think that
absolute super-tight security isn't all that necessary for ZFS, since
the hash isn't used for security purposes. We only need something that's
fast and has a good pseudo-random output distribution. That's why I
looked toward Edon-R. Even though it might have security problems in
itself, it's by far the fastest algorithm in the entire competition.

zfs-discuss mailing list

Reply via email to