Precisely, I said the same thing a few posts before:
dedup=verify solves that. And as I said, one could use dedup=<hash
an inferior hash algorithm (that is much faster) with the purpose of
reducing the number of dedup candidates.
For that matter one could use a trivial CRC32, if the two blocks have the
same CRC you do anyway a
byte-to-byte comparison, but if they have differenct CRC's you don't need
to do the actual comparison.
On Wed, Jul 11, 2012 at 12:24 PM, Justin Stringfellow <
> >>You do realize that the age of the universe is only on the order of
> >>around 10^18 seconds, do you? Even if you had a trillion CPUs each
> >>chugging along at 3.0 GHz for all this time, the number of processor
> >>cycles you will have executed cumulatively is only on the order 10^40,
> >>still 37 orders of magnitude lower than the chance for a random hash
> Here we go, boiling the oceans again :)
> >Suppose you find a weakness in a specific hash algorithm; you use this
> >to create hash collisions and now imagined you store the hash collisions
> >in a zfs dataset with dedup enabled using the same hash algorithm.....
> Sorry, but isn't this what dedup=verify solves? I don't see the problem
> here. Maybe all that's needed is a comment in the manpage saying hash
> algorithms aren't perfect.
> zfs-discuss mailing list
zfs-discuss mailing list