http://qs321.pair.com?node_id=11118270

bbs2web has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I found the following script many years ago and it's been absolutely invaluable in providing for local or network based block device replication. Part of it's neat beauty is that it's trivial to simply copy & paste the lines on a Linux host's shell prompt. It essentially reads data from both source and either local or remote destination block devices (could be entire drive, partition, md device or in our case a Ceph RBD image) in 4 MiB chunks. If the chunk's md5 checksum matches it skips ahead, otherwise it overwrites that chunk.

We are however increasingly being bottle necked by the MD5 hashing function and were wondering if anyone had recommendations on replacing the calls with something that could perhaps offload the hashing to an Intel CPU's AES instructions.


Local block devices:
export srcdev=`rbd map rbd_ssd/vm-277-disk-0`; [ -z $srcdev ] && exi +t 1 # eg: /dev/rbd47 export dstdev=`rbd map rbd_ssd/vm-472-disk-0`; [ -z $dstdev ] && exi +t 1 # eg: /dev/rbd48 perl -'MDigest::MD5 md5' -ne 'BEGIN{$/=\4194304};print md5($_)' $dst +dev | perl -'MDigest::MD5 md5' -ne 'BEGIN{$/=\4194304};$b=md5($_); read STDIN,$a,16;if ($a eq $b) {print "s"} else {print "c" . $_} +' $srcdev | perl -ne 'BEGIN{$/=\1} if ($_ eq"s") {$s++} else {if ($s) { seek STDOUT,$s*4194304,1; $s=0}; read ARGV,$buf,4194304; print $ +buf}' 1<> $dstdev;

Local source to remote block devices:

On source system:
export remote='root@zajnb01-kvm5f.mirror.ad.company.co.za'; export dstdev=`ssh -i /root/.ssh/rsync_rsa $remote "rbd map rbd_ssd/ +vm-277-disk-0`; [ -z $srcdev ] && exit 1"; # or map the image on the destination host and program the variabl +e manually on the source system, for example: # export dstdev='/dev/rbd320'; ssh -i /root/.ssh/rsync_rsa $remote " perl -'MDigest::MD5 md5' -ne 'BEGIN{\$/=\4194304};print md5(\$_)' $d +stdev | lzop -c" | lzop -dc | perl -'MDigest::MD5 md5' -ne 'BEGIN{$/=\4194304};$b=md5($ +_); read STDIN,$a,16;if ($a eq $b) {print "s"} else {print "c" . $_}' +$srcdev | lzop -c | ssh -i /root/.ssh/rsync_rsa $remote "lzop -dc | perl -ne 'BEGIN{\$/=\1} if (\$_ eq\"s\") {\$s++} else {if (\$s) { seek STDOUT,\$s*4194304,1; \$s=0}; read ARGV,\$buf,4194304; print +\$buf}' 1<> $dstdev";

Unallocated, discarded or trimmed blocks read as zeros so read speeds accelerate to GiB/s levels where Perl's MD5 hashing function then becomes the bottleneck. Another thread (860184) referencing possibly skipping the MD5 check if buffers matched. I presume that wouldn't be easy to do on the network based iteration above although it would still save time one some operations...


Regards
David Herselman

Replies are listed 'Best First'.
Re: Could SHA encode faster than MD5?
by Perlbotics (Archbishop) on Jun 20, 2020 at 18:22 UTC

    Perhaps, you should check first if your script runs the pure Perl implementation which is pretty slow.

    A first indicationt that you are running the pure Perl version would be that the following script outputs a proper version number:

    $PATH_TO_YOUR_PERL_BIN/perl -MDigest::MD5 -e 'print "MD5 PP ver. = $Di +gest::Perl::MD5::VERSION\n";'
    If it outputs no version number, you're likely running the XS version that is a wrapper to a fast C implementation.

    Update: Perhaps, you can achieve the same effect using rsync? Seems, it can operate on --devices too.

    This option causes rsync to transfer character and block device files to the remote system to recreate these devices. ...

Re: Could SHA encode faster than MD5?
by tobyink (Canon) on Jun 20, 2020 at 22:22 UTC

    If you want a fast hash but don't care about it being cryptographically strong, something like xxHash or CRC32 is probably your best bet.

Re: Could SHA encode faster than MD5?
by Anonymous Monk on Jun 23, 2020 at 21:01 UTC
    If the only thing that you need to know is that "the data is probably different," and you expect that if it is different it will be very different, then a simple CRC-32 or CRC-64 digest is often enough. It is extremely fast. See preshing.com/20110504/hash-collision-probabilities/
A reply falls below the community's threshold of quality. You may see it by logging in.