Precisely, I said the same thing a few posts before: dedup=verify solves that. And as I said, one could use dedup=<hash algorithm>,verify with 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 < justin.stringfel...@btinternet.com> wrote: > >>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 > >>collision. > > 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. > > cheers, > --justin > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
