<div dir='auto'>It's not a GPFS issue per se.  The changelog isn't quite there right now but will be.  Today the question only is about rsync performance.<div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Bill</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jun 17, 2019 11:04 AM, John Hearns via Beowulf <beowulf@beowulf.org> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Probably best asking this question over on the GPFS mailing list.</div><div><br /></div><div>A bit of Googling reminded me of   <a href="https://www.arcastream.com/">https://www.arcastream.com/</a> They are active in the UK Academic community,</div><div>not sure about your neck of the woods.</div><div>Give them a shout though and ask for Steve Mackie. <a href="http://arcastream.com/what-we-do/">http://arcastream.com/what-we-do/</a></div></div></div></div><br /><div class="elided-text"><div dir="ltr">On Mon, 17 Jun 2019 at 15:39, Michael Di Domenico <<a href="mailto:mdidomenico4@gmail.com">mdidomenico4@gmail.com</a>> wrote:<br /></div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb( 204 , 204 , 204 );border-left-width:1px;border-left-style:solid">rsync on 10PB sounds painful.  i haven't used GPFS in a very long<br />
time, so i might have a gap in knowledge.  but i would be surprised if<br />
GPFS doesn't have a changelog, where you can watch the files that<br />
changed through the day and only copy the ones that did?  much like<br />
what robinhood does for lustre.<br />
<br />
On Mon, Jun 17, 2019 at 9:44 AM Bill Wichser <<a href="mailto:bill@princeton.edu">bill@princeton.edu</a>> wrote:<br />
><br />
> We have moved to a rsync disk backup system, from TSM tape, in order to<br />
> have a DR for our 10 PB GPFS filesystem.  We looked at a lot of options<br />
> but here we are.<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 />
><br />
> Googling around, I found no mention of using a technique like this to<br />
> improve rsync performance.  I did find reference to a few hashing<br />
> algorithms though which could certainly work here (xxhash, murmurhash,<br />
> sbox, cityhash64).<br />
><br />
> Rsync has certainly been around for a few years!  We are going to pursue<br />
> changing the current checksum algorithm and using something much faster.<br />
>   If anyone has done this already and would like to share their<br />
> experiences that would be wonderful. Ideally this could be some optional<br />
> plugin for rsync where users could choose which checksummer to use.<br />
><br />
> Bill<br />
> _______________________________________________<br />
> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">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">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br />
_______________________________________________<br />
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">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">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br />
</blockquote></div>
</blockquote></div><br></div>