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 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=on' 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 (== 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>