Linked by Thom Holwerda on Mon 2nd Nov 2009 23:20 UTC
Thread beginning with comment 392785
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Clarification requested
by Kebabbert on Wed 4th Nov 2009 15:57
in reply to "RE: Clarification requested"
Standard chksum algorithm is SHA256. Incidentally, Niagara SPARC computes SHA256 in chip hardware, achieving 41GB/sec.
You can also choose to use fletcher4, which is very fast but not cryptographically strong. Which means that there is a very low probability of yielding a collision.
With SHA256, the chance of a collision is 2^(-256) which is extremely extremely low probability. Maybe it is like 10^(-71) or so for two differing blocks to collide.
But, you can request that if there is a hash collision, ZFS must compare bit for bit. This makes dedupe totally safe against collisions.






Member since:
2009-07-10
I would *expect* to be the same as with compression= and checksum= options.
For example if you switch your checksumming algorithm from A to B, the old files are using A and new files B. Or, if you enable compression in a dataset that already has uncompressed files, they remain uncompressed. Only newly created files are affected.