So, from what I gather, even though the documentation appears to state otherwise, default checksums have been changed to SHA256. Making that assumption, I have two questions. First, is the default updated from fletcher2 to SHA256 automatically for a pool that was created with an older version of zfs and then upgraded to the latest? Second, would all of the blocks be re-checksummed with a zfs send/receive on the receiving side? --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20091023/c5e7afd9/attachment.html>
On Fri, Oct 23, 2009 at 06:55:41PM -0500, Tim Cook wrote:> So, from what I gather, even though the documentation appears to state > otherwise, default checksums have been changed to SHA256. Making that > assumption, I have two questions.That''s false. The default checksum has changed from fletcher2 to fletcher4 that is to say, the definition of the value of ''on'' has changed.> First, is the default updated from fletcher2 to SHA256 automatically for a > pool that was created with an older version of zfs and then upgraded to the > latest? Second, would all of the blocks be re-checksummed with a zfs > send/receive on the receiving side?As with all property changes, new writes get the new properties. Old data is not rewritten. Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
On Fri, Oct 23, 2009 at 7:19 PM, Adam Leventhal <ahl at eng.sun.com> wrote:> On Fri, Oct 23, 2009 at 06:55:41PM -0500, Tim Cook wrote: > > So, from what I gather, even though the documentation appears to state > > otherwise, default checksums have been changed to SHA256. Making that > > assumption, I have two questions. > > That''s false. The default checksum has changed from fletcher2 to fletcher4 > that is to say, the definition of the value of ''on'' has changed. > > > First, is the default updated from fletcher2 to SHA256 automatically for > a > > pool that was created with an older version of zfs and then upgraded to > the > > latest? Second, would all of the blocks be re-checksummed with a zfs > > send/receive on the receiving side? > > As with all property changes, new writes get the new properties. Old data > is not rewritten. > > Adam > >Adam, Thank you for the correction. My next question is, do you happen to know what the overhead difference between fletcher4 and SHA256 is? Is the checksumming multi-threaded in nature? I know my fileserver has a lot of spare cpu cycles, but it would be good to know if I''m going to take a substantial hit in throughput moving from one to the other. --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20091023/ca92f094/attachment.html>
> Thank you for the correction. My next question is, do you happen to > know what the overhead difference between fletcher4 and SHA256 is? > Is the checksumming multi-threaded in nature? I know my fileserver > has a lot of spare cpu cycles, but it would be good to know if I''m > going to take a substantial hit in throughput moving from one to the > other.Tim, That all really depends on your specific system and workload. As with any performance related matter experimentation is vital for making your final decision. Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
Thanks for the update Adam, that''s good to hear. Do you have a bug ID number for this, or happen to know which build it''s fixed in? -- This message posted from opensolaris.org
Hi Ross, The CR ID is 6740597: zfs fletcher-2 is losing its carries Integrated in Nevada build 114 and the Solaris 10 10/09 release. This CR didn''t get a companion man page bug to update the docs so I''m working on that now. The opensolaris.org site seems to be in the middle of its migration so I can''t refer to the public bug database. Cindy On 10/26/09 01:00, Ross wrote:> Thanks for the update Adam, that''s good to hear. Do you have a bug ID number for this, or happen to know which build it''s fixed in?