This is great! However, do you have access to a big-endian CPU? I'm
not sure how relevant this still is but I've read at some point that
xxhash might have produced different (reverse?) hashes on different
endian CPUs. It may be prudent to acutally test if that is the case
with this implementation
That's excellent news!
On Sat, 23 May 2020 at 08:11, Wayne Davison via rsync
wrote:
> On Tue, Oct 1, 2019 at 8:02 AM Bill Wichser via rsync <
> rsync@lists.samba.org> wrote:
>
>> Attached is the patch we applied [to add xxhash checksums]
>
>
> Thanks, Bill! I finally got around to finishing up
On Tue, Oct 1, 2019 at 8:02 AM Bill Wichser via rsync
wrote:
> Attached is the patch we applied [to add xxhash checksums]
Thanks, Bill! I finally got around to finishing up some checksum
improvements and have added support for xxhash in the master branch. The
latest version in git now picks
Paul,
Thanks. I can see your point for sure. I wasn't suggesting an all out
switch but just an option to use with a flag. Since we're using a GPFS
to GPFS transfer over a high speed link, doing billions of files at the
moment, even a marginal increase in speed helps and is why we were using
On Tue 01 Oct 2019, Bill Wichser via rsync wrote:
>
> Attached is the patch we applied. Since xxhash is in the distro, a
> dependency would be required for this RPM. If nothing else, perhaps the
> developers should just take a look as this could benefit many.
"The distro" is a bit vague for a
Back in the spring, we started using rsync for a disk to disk backup
system maintaining close to 10PB of data. I am not here to debate the
issue of what is the right tool but only to discuss what we found to be
a problem with rsync when doing so.
We traced the various processes hoping to
