<div dir="ltr">I know that at one point, some Intel chips had instruction extensions available to speed up SHA checksums by computing them directly in hardware.  Might be worth looking into: <a href="https://software.intel.com/en-us/articles/intel-sha-extensions">https://software.intel.com/en-us/articles/intel-sha-extensions</a><div><br></div><div>More recently, Intel has been promoting QuickAssist/QAT, which also seems to perform hardware acceleration for SHA algorithms (seems like a possible re-branding / architecture recycling).  There's some integration with ZFS for this.  <a href="https://drive.google.com/file/d/0B_J4mRfoVJQRV3ZOd1ZMWkphcV9OYXdWT0FBblVHbVZpSmZj/view">https://drive.google.com/file/d/0B_J4mRfoVJQRV3ZOd1ZMWkphcV9OYXdWT0FBblVHbVZpSmZj/view</a></div><div><br></div><div>SPARC has also had a large number of cipher algorithms hardwired into its architecture recently (what Oracle is calling "Software in Silicon").  See <a href="http://storageconference.us/2017/Presentations/Phillips.pdf">here</a>.  Of course, to take advantage of this technology you'd have to deal with Oracle, as well as an increasingly uncommon CPU architecture.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 17, 2019 at 12:34 PM Loncaric, Josip via Beowulf <<a href="mailto:beowulf@beowulf.org">beowulf@beowulf.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why not use existing pftool?<br>
<br>
<a href="https://github.com/pftool/pftool" rel="noreferrer" target="_blank">https://github.com/pftool/pftool</a><br>
<br>
-Josip<br>
<br>
On 6/17/19 10:07 AM, Michael Di Domenico wrote:<br>
> just out of morbid curiosity i popped through the rsync code.  it<br>
> doesn't look terribly difficult to wedge in a new algo.  but honestly,<br>
> if i was going to go through the trouble i'd write a new tool that<br>
> walks the file tree in parallel and logs the checksums to a database.<br>
> i've had problems rsync'ing big filesystems in the past, so i try to<br>
> avoid it as a DR or poor-man's snapshotting<br>
><br>
> On Mon, Jun 17, 2019 at 11:30 AM Christopher Samuel <<a href="mailto:chris@csamuel.org" target="_blank">chris@csamuel.org</a>> wrote:<br>
>> On 6/17/19 6:43 AM, Bill Wichser wrote:<br>
>><br>
>>> md5 checksums take a lot of compute time with huge files and even with<br>
>>> millions of smaller ones.  The bulk of the time for running rsync is<br>
>>> spent in computing the source and destination checksums and we'd like to<br>
>>> alleviate that pain of a cryptographic algorithm.<br>
>> First of all I would note that rsync only uses checksums if you tell it<br>
>> to, otherwise it just uses file times and sizes to determine what to<br>
>> transfer.<br>
>><br>
>> rsync is also single-threaded, so I would take a look at what was<br>
>> previously called parsync, but is now parsynfp :-)<br>
>><br>
>> <a href="http://moo.nac.uci.edu/~hjm/parsync/" rel="noreferrer" target="_blank">http://moo.nac.uci.edu/~hjm/parsync/</a><br>
>><br>
>> There is the caveat there though:<br>
>><br>
>> # As a warning, the main use case for parsyncfp is really only<br>
>> # very large data transfers thru fairly fast network connections<br>
>> # (>1Gb). Below this speed, rsync itself can saturate the<br>
>> # connection, so there’s little reason to use parsyncfp and in<br>
>> # fact the overhead of testing the existence of and starting more<br>
>> # rsyncs tends to worsen its performance on small transfers to<br>
>> # slightly less than rsync alone.<br>
>><br>
>> Good luck!<br>
>> Chris<br>
>> --<br>
>>     Chris Samuel  :  <a href="http://www.csamuel.org/" rel="noreferrer" target="_blank">http://www.csamuel.org/</a>  :  Berkeley, CA, USA<br>
>> _______________________________________________<br>
>> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
>> To change your subscription (digest mode or unsubscribe) visit <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br>
> _______________________________________________<br>
> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
> To change your subscription (digest mode or unsubscribe) visit <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br>
<br>
<br>
-- <br>
Dr. Josip Loncaric, LANL, MS-T001, P.O. Box 1663, Los Alamos, NM 87545<br>
mailto:<a href="mailto:josip@lanl.gov" target="_blank">josip@lanl.gov</a>   Cell: +1-505-412-8490   Phone: +1-505-412-6538<br>
--<br>
E Pluribus Unum<br>
<br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br>
</blockquote></div>