Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 2017/08/29 6:28 AM, Digimer wrote: > On 2017-08-28 09:28 PM, 大川敬臣 wrote: >> I want to enable checksum-based synchronization by adding "csums-alg >> <algorithm>" to drbd.conf. >> [...] >> The algorithms (sha1, md5, crs32) are king of old ones. Can I use sha256? >> Is there some reason that sha256 is not used? >> > So the real question is; How concerned are you that a) two > blocks don't match and b) those differences are just perfectly different > to cause a hash collision/false match? Exactly. B) is very unlikely to be caused coincidentally, it's not even easy to create a hash collision intentionally, since hashing algorithms are specifically designed to make such collisions unlikely. > The stronger the algorithm, the more load it will place on the system. I > would stick with something fast, maybe md5 at the most. In general, yes, but not necessarily. SHA1 is typically only slightly slower than MD5, but much safer. With SHA2, SHA512 is actually significantly faster than SHA256 on 64 bit architectures. SHA224 is basically SHA256 with truncated output, and SHA384 is basically SHA512 with truncated output, so those will not improve performance over the version with full output length. Very recent CPUs come with Intel's SSE SHA Instructions, those support SHA1 and SHA256, and using a special processor instruction will typically be faster than running most algorithms in software - so CPU-supported SHA256 may be faster than software-supported MD5. However, I doubt that there is already support for these instructions in the software or the compilers, because the instructions have only recently made it into Intel and AMD processors (the specification itself however is from 2013). Enough theory though, in my opinion, for just creating checksums, it does not really matter a lot which algorithm you use. Personally, I'd probably choose SHA1. Cheers, Robert