Date: Sat, 11 Jun 2011 23:58:39 -0400 From: David Magda <dmagda@ee.ryerson.ca> To: Volodymyr Kostyrko <c.kworr@gmail.com> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Martin Matuska <mm@freebsd.org> Subject: Re: HEADS UP: ZFS v28 merged to 8-STABLE Message-ID: <525D503A-240C-49F2-9AAD-EC8E3C1CDB9A@ee.ryerson.ca> In-Reply-To: <4DF28BCF.3060008@gmail.com> References: <4DECB197.8020102@FreeBSD.org> <4DF28BCF.3060008@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 10, 2011, at 17:25, Volodymyr Kostyrko wrote: > Am I missing something? How about using fletcher[24] for dedup? Fletcher is fairly weak as things go, and so even though two checksums = are the same, there's a decent chance that the data is actually = different. At least with recent releases of (Open)Solaris, when you = enable do a 'dedup=3Don' the has used is SHA-256, which has very, very, = very, low odds of having the same value occur from two different blocks = of data. When ZFS dedupe originally came out you could have one of the following = values: . off . on (=3D=3D sha256) . flecther4 with verify/compare . sha256 (without verify/compare) . sha256 with verify There was a long-ish thread on zfs-discuss fairly recently on whether = SHA-256 was "good enough" where you could trust it, or whether one = should do a verify step in addition to SHA-256: = http://mail.opensolaris.org/pipermail/zfs-discuss/2011-January/046875.html= While some people argued that it was prudent to use "verify" (especially = with your data/job on the line), a good portion of folks though said = that it's not worth it (i.e., if you're not worried about being hit by = lightning (2^-17 to 2^-18), you shouldn't be worried about a hash = collision (2^-128)).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?525D503A-240C-49F2-9AAD-EC8E3C1CDB9A>