Re: Rsync 3.2.3pre1 released

> On 28 Jul 2020, at 20:53, Nelson H. F. Beebe via rsync > wrote: > > To my surprise, ALL of the builds failed, and examination of the build > logs showed they were all due to missing libraries or header files, > notably for one or more of lz4, openssl, xxhash, and zstd. Once I > installed thos

Re: [PATCH] SSE2/SSSE3 optimized version of get_checksum1() for x86-64

> On 18 May 2020, at 19:02, Jorrit Jongma wrote: > > I think you're missing a point here. Two different checksum algorithms > are used in concert, the Adler-based one and the MD5 one. I > SSE-optimized the Adler-based one. The Adler-based hash is used to > _find_ blocks that might have shifted, w

Re: [PATCH] SSE2/SSSE3 optimized version of get_checksum1() for x86-64

Thank you Jorrit for your detailed answer. > On 18 May 2020, at 17:58, Jorrit Jongma via rsync > wrote: > > Well, don't get too excited, get_checksum1() (the function optimized > here) is not the great performance limiter in this case, it's > get_checksum2() and sum_update(), which will be usin

Re: [PATCH] SSE2/SSSE3 optimized version of get_checksum1() for x86-64

> On 18 May 2020, at 17:06, Jorrit Jongma via rsync > wrote: > > This drop-in patch increases the performance of the get_checksum1() > function on x86-64. As ref, rather related to this : https://bugzilla.samba.org/show_bug.cgi?id=13082 Than

Re: Enabling easier contributions to rsync

> On 26 Apr 2020, at 20:37, Filipe Maia via rsync wrote: > > Hi, > > Are there plans to soon move to github or some other place where people can > easily contribute to rsync, making the software discussion more lively and > productive? > I've seen several useful patches being submitted (e.g.

Re: --link-dest. Time to 'building file list' incrementing

Hi, As you are on Cygwin, you should consider the notexec & noacl mount options : https://cygwin.com/cygwin-ug-net/using.html#mount-table They impact stat() performance. Ben > On 8 Jan 2019, at 10:56, John Simpson via rsync wrote: > >

Re: rsync of a reflink from OCFS2

read the remote file over the network in order to do the diff then it would write the whole file over the network anyway (--inplace would help a little). Local copies force --whole-file for a good reason. On 03/14/2018 10:05 AM, Ben RUBSON via rsync wrote: On 14 Mar 2018, Lentes, Bernd via rsync

Re: rsync of a reflink from OCFS2

On 14 Mar 2018, Lentes, Bernd via rsync wrote: - On Mar 14, 2018, at 2:19 PM, Ben RUBSON ben.rub...@gmail.com wrote: On 14 Mar 2018, Lentes, Bernd via rsync wrote: I would now expect a rsync from the snap would transfer just some megay bytes to the file from the day before. But it

Re: rsync of a reflink from OCFS2

On 14 Mar 2018, Lentes, Bernd via rsync wrote: I would now expect a rsync from the snap would transfer just some megay bytes to the file from the day before. But it doesn't: ha-idg-1:/cluster/guests/servers_alive # time rsync -av --stats sa.raw.snap /mnt/idg-2/SysAdmin_AG_Wurst/backup/clust

Re: file contents cause rsync to fail (with certains args and dir structure)

On 05 Mar 2018 11:14, Dave Gordon via rsync wrote: Problem was introduced with this commit: commit f3873b3d88b61167b106e7b9227a20147f8f6197 Author: Wayne Davison Date: Mon Oct 10 11:49:50 2016 -0700 Support --sparse combined with --preallocate or --inplace. The new code tries to pu

Re: Rsync and client-side encryption of files

On 11 Jan 2018 03:29, H via rsync wrote: Is anyone using client-side encryption of files before transferring them to a cloud server using Rsync? I am running CentOS.-- A solution could be EncFS in reverse mode. Ben -- Please use reply-all for most replies to avoid omitting the mailing list.

Re: rsync does hours of "fake-work" after failure

> On 06 Oct 2017, at 13:18, Frank Steiner wrote: > > Ben RUBSON wrote >> >> I encountered same issue and proposed the following patch : >> https://bugzilla.samba.org/show_bug.cgi?id=12525 > > Sorry, I really missed that as my search keywords were completely

Re: rsync does hours of "fake-work" after failure

> On 06 Oct 2017, at 12:24, Frank Steiner via rsync > wrote: > > Hi, > > I just stepped on a strange and very annoying bug in rsync-3.1.0 as > shipped with SuSE Linux Enterprise 12, but verified the bug also > with rsync-HEAD-20170123. > > I tried to copy some of my movie collection to a usb d

Re: [Bug 12819] [PATCH] sync() on receiving side for data consistency

> On 15 Jun 2017, at 19:29, Karl O. Pinc via rsync > wrote: > > On Thu, 15 Jun 2017 13:23:44 + > just subscribed for rsync-qa from bugzilla via rsync > wrote: > >> https://bugzilla.samba.org/show_bug.cgi?id=12819 >> >> --- Comment #7 from Ben RUBS

Re: Huge directory tree: Get files to sync via tools like sysdig

> On 10 Feb 2017, at 01:21, Karl O. Pinc wrote: > > On Fri, 10 Feb 2017 12:38:32 +1300 > Henri Shustak wrote: > >> As Ben mentioned, ZFS snapshots is one possible approach. Another >> approach is to have a faster storage system. I have seen considerable >> speed improvements with rsync on simil

Re: Huge directory tree: Get files to sync via tools like sysdig

> On 09 Feb 2017, at 16:10, Thomas Güttler wrote: > > Am 09.02.2017 um 11:05 schrieb Ben RUBSON: >>> On 09 Feb 2017, at 10:05, Thomas Güttler >>> wrote: >>> >>> Hi, >>> >>> we have a huge directory tree. >>> >&g

Re: Huge directory tree: Get files to sync via tools like sysdig

> On 09 Feb 2017, at 10:05, Thomas Güttler wrote: > > Hi, > > we have a huge directory tree. > > > * 17M files (number of files) > * 2.2TBytes of data. > * Only 0.1% changes per day > > Current pain: rsyncs directory tree traversal needs to long to discover the > changed files. Hi, On whic

Re: link-dest + fuzzy twice = vanished

I just submitted a bug report : https://bugzilla.samba.org/show_bug.cgi?id=12489 -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-

link-dest + fuzzy twice = vanished

Hello, I use --link-dest which works perfectly : rsync -a -R --link-dest="../2016-12-28/" --link-dest="../2016-12-27/" /my/backup/folder ::daemon/mycomputer/2016-12-29/ Now I would like to use --fuzzy --fuzzy, so that rsync algorithm can also work with similarly named files found in other link-

link-dest / checksum / db.diff

Hello, I use rsync (3.0.9) to make backups with the link-dest option, so that I keep daily folders, and I only upload the difference. However, when a directory is moved somewhere else in the tree, it is fully re-uploaded. Same thing when files are simply renamed, they are re-uploaded, not linked.