ZFS Checksum Parameter: Info to help me pick my poison
807557Nov 29 2007 — edited Mar 27 2009I have a request for information which I see as fundamental to using ZFS.
It would be valuable if Sun were to provide more information to guide the user in setting of the ZFS Checksum parameter. Specifically, to provide nuts-and-bolts practical information regarding the failure modes and reliability levels of the various options, fletcher2 vs. fletcher4 vs. SHA256. Relative performance as well as benchmarks on a couple of arbitrary contemporary platforms to calibrate the reader would also be helpful, but that is secondary since people can always run tests.
I am aware of the following information, and explain why I do not believe that it meets the user's needs:
The best (Only?) previous answer has been in Dmitry Mozheyko's post on Jan 2, 2007 refering people to wikipedia articles which provide a general overview of checksums, and if you continue to dig, mathematical definitions of the algorithms and code. The best paper I found in this dig was "Performance of Checksums and CRCs over Real Data" by Stone et al., but this was targetted at specific system failure modes in an ATM system, making it difficult to extrapolate with confidence in a direction that it does not explore: That of failure modes that might occur in a ZFS file system. Furthermore, while it seems reasonable to guess that Fletcher2 refers to fletcher's version with 8 bit sums, and fletcher4 to his verison with 16 bit sums, and that ZFS uses the two's complement version since both SPARC and x86 are two's complement machines, all this is conjecture. This information would be valuable in order to associate literature results with ZFS parameters.
The statement in section 4.4.3 of Jeff Bonwick's "Case Materials for PSARC 2002/240 'ZFS (Zettabyte Filesystem)'" that the "standard" 64 bit checksum algorithm (Documented as Fletcher2 in the administration guide) provides a 10E-19 probability (2E-64, corresponding to the number of unique checksum values) of error is overly simplistic and misleading to the uninformed. Typical checksums completely cover certain classes of errors, leave other classes completely undetected, and have spotty coverage of everything else. This of course has to be, since one cannot encode a 512 byte sector of arbitrary data into 64 bits! The classes and probabilities depend on the algorithm. Different algorithms have different characteristics, some are really crummy, some are really excellent.
Also note that the "standard" (fletcher2) algorithm having a 64 bit checksum is inconsistent with any correlation of fletcher2 and fletcher4 with the 8 bit sum (16 bit checkword) and 16 bit sum (32 bit checkword) proposed by Fletcher. So anything I think I may have learned from any literature is totally out the window! I expect that SUN has extrapolated Fletcher's algorithm to wider words, but I don't know exactly how, and I don't understand the implications to error detection other than a simple minded "Bigger is Better".
In short, I have expended a considerable effort to locate and digest information on the subject, yet have not been able to build a sufficient understanding to make a decision with much of an inkling of what I am getting. I am simply confused at a deeper and more significant level ;-).
While I think it is valuable (actually great!) to provide the user with the ability to trade data integrity off against performance, the typical user does not have the knowlege to make a selection based on simple the names "fletcher2", "fletcher4", and "sha256". In fact, probably almost nobody does.
It would be extremely helpful to provide in the documentation a technically oriented but down-to-earth nuts-and-bolts practical paragraph for each algorithm to enable the data owner to pick their poison (Risk vs. speed) intelligently! Don't provide a Windows-Idiot description, but one targeting an intelligent engineer who doesn't know about the mathematics of hash functions, with a sentence steering those who don't fit this model. Everyone will be served. Data security is THE reason for ZFS' existence; surely this topic deserves a half a page to a page in the manual!
Please help this note to travel to someone who can whip off a simple, insightful answer in a few minutes (For my immediate benefit!), and further to put it in Table 5-1 "Introducing ZFS Properties" in the "ZFS Administration Guide", or perhaps an appendix for future generations!
Thanks for whatever help you can provide!
Ray Clark