[DRBD-user] csums-alg,verify-alg algorithm

Jan Schermer jan at schermer.cz
Thu Aug 31 10:24:36 CEST 2017

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


There are algorithms suitable for detecting or correcting flipped bits, like CRC32 or even fletcher4 that ZFS uses for checksums.
Those are _NOT_ suitable for comparing data, think of them more like parity, and you WILL have false matches with them even without having lots of data as they are not collision resistant at all.
Then there are collision resistant algorithms as already outlined below.

I chose SHA512 because it’s only 20% slower than SHA1 and only about 5% slower than MD5, and in any case unlikely to cause a bottleneck when resyncing or even reading data most of the time.

Jan

> On 31 Aug 2017, at 10:12, 大川敬臣 <yoshiomi-okawa at kccs.co.jp> wrote:
> 
> Thank you all .
> 
> I will discuss with my team and decide it.
> Your advice helped me!!
> 
> Thanks,
> 
> 2017-08-30 10:20 GMT+09:00 Robert Altnoeder <robert.altnoeder at linbit.com <mailto:robert.altnoeder at linbit.com>>:
> 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
> 
> 
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com <mailto:drbd-user at lists.linbit.com>
> http://lists.linbit.com/mailman/listinfo/drbd-user <http://lists.linbit.com/mailman/listinfo/drbd-user>
> 
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20170831/65e070e7/attachment.htm>


More information about the drbd-user mailing list