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. Cheers, -- Saso _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
