Re: [PATCH] Reduce memory usage

[Rupert Gallagher via rsync]

 Original Message 
On Oct 2, 2021, 15:04, Jindřich Makovička < makov...@gmail.com> wrote:
Just note this patch has nothing to do with memory consumption vs performance. 
It just avoids allocating memory that was left unused anyway.

I can read-- 
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-questions.html

Re: Aw: Re: [PATCH] Reduce memory usage

[Rupert Gallagher via rsync]

 Original Message 
On Oct 2, 2021, 12:36, < devz...@web.de> wrote:
>>In the exchange I argued that proper use of ram as a buffer would have cut 
>>down backup time to minutes instead of days.

>could you give an example where rsync is slowing things down so much due to 
>ram constraints or inefficient ram use?

You find it all in the exchange I already referred to.

>please mind that disk bandwith and file copy bandwith is not the same. random 
>i/o and seek time is the culprit.

I am glad you did your homework.

>why should rsync use ram for buffering data it copies, if the linux kernel / 
>vm subsystem already does this?

Because my server is not using linux?-- 
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-questions.html

Re: [PATCH] Reduce memory usage

[Rupert Gallagher via rsync]

If you look at my previous exchange in the list, I raised the need for more ram 
usage via a tool option. In the exchange I argued that proper use of ram as a 
buffer would have cut down backup time to minutes instead of days. At the time, 
my proposal was dismissed by someone saying that rsync uses as much ram as it 
needs. I still feel the need to free rsync from this mindless constraint, while 
also welcoming ram usage optimisations such as yours in this patch. How hard 
can it be to allow rsync to use 1GB of ram instead of 100MB? The benefit would 
be huge. In my case, where a supermicro server uses a shared bus to transfer 
data from two disks, the overhead caused by frequent small buffer IO is so high 
that backup time is still huge. And I am using server hardware! PC and laptops 
are even worse.

RG

 Original Message 
On Sep 26, 2021, 13:54, Jindřich Makovička via rsync < rsync@lists.samba.org> 
wrote:
Hi,

When using rsync to back up the file system on my laptop, containing a pretty 
much default linux desktop, I was wondering how rsync uses over 100MB of RAM it 
allocates.

It turned out that most of the memory is used for the arrays of file_struct 
pointers, most of which end up unused - much more than the actual file_struct 
entries. In my case, the peak usage was 135MB of pointers, and just 1.5MB of 
the file_struct entries themselves.

The problem seems to be that the default file_list allocation parameters 
predate the incremental recursion, which allocates a huge number of small file 
lists, while AFAICS originally rsync allocated just one large list.

Applying the attached patch, which reduces the default allocation to 32 
pointers, and preallocates 32K pointers only for the main file lists in 
send_file_list and recv_file_list, reduces the peak memory usage in my case 
from 142MB to 12MB.

Regards,
--
Jindřich Makovička-- 
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-questions.html

Re: Rsync 3.2.2/OSX/ on high bandwidth

[Rupert Gallagher via rsync]

+1

 Original Message 
On Sep 1, 2020, 10:44, Guillaume Bossu via rsync < rsync@lists.samba.org> wrote:
Hello,

First, thanks for your amazing job !
I used rsync on OSX on a 10Gbit network.
Now i move to 50Gbit network but rsync stay to a maximum transfert of 130 MB/s.
I believe that the limit comes from the read block size fixed at 256K.
Could it be changed to 512K or even to 1 000K to enjoy the maximum bandwidth 
available?

Thanks

Guillaume B-- 
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-questions.html

Re: Rsync 3.2.3 released

[Rupert Gallagher via rsync]

The obsd community is silent. There is a thread on misc@ but no participation.

 Original Message 
On 10 Aug 2020, 09:19, < pl...@agora.rdrop.com> wrote:
Rupert Gallagher  wrote:
> ... I see this ball bounched betwen rsync, openbsd and supermicro
> ... I see a large cache delivered by the OS on server hardware and
> a program unable to use it.
It sounds as if the problem may be OpenBSD "delivering" the cache
rather than "utilizing" it. What does the documentation -- or the
OpenBSD support community -- say about configuring OpenBSD to use
that sort of cache for filesystem optimization?-- 
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-questions.html

Re: Rsync 3.2.3 released

[Rupert Gallagher via rsync]

Beach ball play is fun, but I see this ball bounched betwen rsync, openbsd and 
supermicro, and I am not enjoying it. I see a large cache delivered by the OS 
on server hardware and a program unable to use it.

 Original Message 
On 8 Aug 2020, 20:14, < pl...@agora.rdrop.com> wrote:
Rupert Gallagher via rsync  wrote:
> On 7 Aug 2020, 23:44, Wayne Davison < wa...@opencoder.net> wrote:
>
> >> Also, I have 12GB of cache in ecc ram that rsync is not using.
>
> >It uses whatever memory it needs plus whatever filesystem caching
> >your OS provides.
>
> Hmmm... bad day today...
>
> No, it is not using all available resources. It is doing frantic
> I/O instead of buffering. The result is a appalling low transfer
> rate.
This is an OS configuration/tuning problem, not an rsync problem.
Application-level code (such as rsync) does not directly deal with
NUMA features such as external RAM banks. Support for that sort of
thing would normally be provided by the OS memory management and
filesystem code -- but (depending on the hardware details) it might
need configuration or even a specialized driver.-- 
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-questions.html

Re: Rsync 3.2.3 released

[Rupert Gallagher via rsync]

 Original Message 
On 7 Aug 2020, 23:44, Wayne Davison < wa...@opencoder.net> wrote:

>> Also, I have 12GB of cache in ecc ram that rsync is not using.

>It uses whatever memory it needs plus whatever filesystem caching your OS 
>provides.

Hmmm... bad day today...

No, it is not using all available resources. It is doing frantic I/O instead of 
buffering. The result is a appalling low transfer rate.-- 
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-questions.html

Re: Rsync 3.2.3 released

[Rupert Gallagher via rsync]

Rsync 3.2.2 ransfer rate on my pet hardware is really poor, so every 
improvement counts.

I noted that rsync writes a gmon file on the source path and leaves it there 
when it terminates. When the source path is read-only, rsync complains that it 
cannot write in it. For optimal use of the input bus, no write commands should 
be used there. Can you look into it?

Also, I have 12GB of cache in ecc ram that rsync is not using. I can tell 
because I see frantic io from the leds of the disks when rsync is the only 
running process. Can you add an option to maximise the use of ram cache?

Thank you!

 Original Message 
On 7 Aug 2020, 07:15, Wayne Davison via rsync < rsync@lists.samba.org> wrote:
I have released rsync 3.2.3. It contains a smattering of bug fixes and various 
enhancements.

To see a summary of all the recent changes, visit this link:

[https://rsync.samba.org/](https://rsync.samba.org/ftp/rsync/NEWS#3.2.3

You can download the source tar file and its signature from here:

[https://rsync.samba.org/](https://rsync.samba.org/ftp/rsync/rsync-3.2.3.tar.gz
[https://rsync.samba.org/](https://rsync.samba.org/ftp/rsync/rsync-3.2.3.tar.gz.asc

See the website for other downloads, including diffs, patches, etc.:

https://rsync.samba.org/

See also rsync on github:

https://github.com/WayneD/rsync

..wayne..-- 
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-questions.html

Re: RAM speedup

[Rupert Gallagher via rsync]

The disk is brand new.

 Original Message 
On 30 Jul 2020, 16:00, Karl O. Pinc < k...@meme.com> wrote:
On Thu, 30 Jul 2020 06:55:00 +
Rupert Gallagher via rsync  wrote:
> I updated the archive disk, it is a 4T WD Red SSD, now copying from
> the old Seagate Exos. Speed is ridiculous: only 80GB copied overnight.
Rsync aside, consumer grade SSDs typically suffer from write
amplification unless up to 20% of the drive is _never_ written to.
The best way to assure this is to leave 20% unpartitioned.
https://en.wikipedia.org/wiki/Write_amplification
Regards,
Karl 
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein-- 
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-questions.html

Re: RAM speedup

[Rupert Gallagher via rsync]

I would not refer to it as consumer: it costs 670 eur, it is specifically 
designed for nas, ans it comes with a 5 years warrantee.

 Original Message 
On 30 Jul 2020, 16:00, Karl O. Pinc < k...@meme.com> wrote:
On Thu, 30 Jul 2020 06:55:00 +
Rupert Gallagher via rsync  wrote:
> I updated the archive disk, it is a 4T WD Red SSD, now copying from
> the old Seagate Exos. Speed is ridiculous: only 80GB copied overnight.
Rsync aside, consumer grade SSDs typically suffer from write
amplification unless up to 20% of the drive is _never_ written to.
The best way to assure this is to leave 20% unpartitioned.
https://en.wikipedia.org/wiki/Write_amplification
Regards,
Karl 
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein-- 
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-questions.html

Re: RAM speedup

[Rupert Gallagher via rsync]

I updated the archive disk, it is a 4T WD Red SSD, now copying from the old 
Seagate Exos. Speed is ridiculous: only 80GB copied overnight.

I need help here-- 
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-questions.html

Re: RAM speedup

[Rupert Gallagher via rsync]

‐‐‐ Original Message ‐‐‐
On Sunday 28 June 2020 21:29, Matthias Schniedermeyer  wrote:

> On 28.06.2020 16:46, Rupert Gallagher wrote:
>
> > ? Original Message ?
> > On Sunday 28 June 2020 13:58, Matthias Schniedermeyer m...@citd.de wrote:
> > destination:
> > ST5000LM000-2AN1 sata hdd
> > Writing speed : 74 MB/s
> > Reading speed : 89 MB/s
>
> And this HDD is a SMR model(*) on top of beeing a 4k sector model emulating 
> 512 byte sectors.
> So alignment needs to be correct and the filesystems must use 4k sectors.
>
> This HDD is NOT suitable for beeing used for small files and a hardlink-farm.
>
> SMR HDDs only reach best performance if used "like a tape drive" with large 
> and linear writing.
>
> I use SMR HDDs myself and only use them for "really large" files (>500MB per 
> file), otherwise they perform very poorly.
> I also align my partitions correctly and set XFS to "4k sector"-size.
> Which nowadaya means: I use 4k sectors for anything. As i only have been
> using 4k sector HDDs for nearly as long as they are on the market (IIRC >1 
> decade).
>
> Also SSDs are usually optimized for 4k sectors too.
>
> *:
> https://en.wikipedia.org/wiki/Shingled_magnetic_recording

SMR is the cost we pay for large storage on small space.
There is something similar to SMR also for SSD, found in Samsung QVO units.

The cost-benefit analysis for 2.5" drives led to this product.

Costs are HDD <= SSD < TAPE (HP LTO Ultrium).

We are using this disk "like a tape drive", with hardlinks because it can.

This is from the current disklabel:

bytes/sector: 512
sectors/track: 255
tracks/cylinder: 511
sectors/cylinder: 130305
cylinders: 74959
total sectors: 9767541168 # total bytes: 4.5T

This is from the current ffs2:

fs block size  : 8192 bytes
Free disk space: 4713572474880 bytes

The values are native, without any tuning.

However, the bottom line is that I get the job done in 2 hours via the lan, and 
8 hours via the bus...


-- 
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-questions.html

Re: RAM speedup

[Rupert Gallagher via rsync]

‐‐‐ Original Message ‐‐‐
On Sunday 28 June 2020 21:09, Matthias Schniedermeyer  wrote:

> > > Complete rsync commandline?
> >
> > /usr/local/bin/rsync --recursive --links --times --modify-window=1 
> > --devices --specials --update --owner --group --perms --delete 
> > --delete-before --delete-excluded 
> > --exclude-from=/etc/excluded_from_backup.conf --numeric-ids --outbuf=Block 
> > --inplace --link-dest=/backup/latest/ /archive /backup

> Linkdest means "more metadata-operations".

The end result is a competitive advantage with respect to brute copying.

> This is a hardlinked backup-store?

Yes

> With or without deletion of older backups?

When the backup disk is full, we either re-format and start fresh if there is a 
single unit, or the backup continues on the second disk with a fresh first copy 
of the archive.

Your very thought that we could be deleting an older backup while pretending to 
read from a broken hard link shows your debugging spirit.

> What is the age of that backup store?

This is a fresh unit.

> Hardlink-farms age a filesystem pretty severely, IOW after some time the 
> freespace gets heavyly fragmented. IOW the HDD has to seek like hell to piece 
> the Meta-data & file-content into many small holes.

The idea with a large disk is to just add up and read occasionally. I do not 
understand what you mean by fragmentation of free space. The drive does its 
job, serving its purpose; reading a file directly is easier on the drive than 
following bread crumbs first, but this is the cost to pay for fast incremental 
backups. The first is hell, the latter are faster. Compare to copying 
everything each time, or copy just the new files and have you manually rebuild 
the full image. I prefer hard links, as it makes life easier.

> Personally i only use hardlink-farms on SSDs nowadays, HDDs "don't really 
> like" hardlink-farms.

For backups and LTANS, the cost-benefit analysis is still in favour of spinning 
disks.

> > > What hardware? (From the numbers it is only clear that you seem to talk 
> > > about HDDs.)
> > > What HDDs?
> >
> > source:
> > ST2000NX0403 sata hdd
> > Writing speed : 117 MB/s
> > Reading speed : 99 MB/s
> > destination:
> > ST5000LM000-2AN1 sata hdd
> > Writing speed : 74 MB/s
> > Reading speed : 89 MB/s

I forgot to tell you, those are measured speeds, writing a single file greater 
than RAM, so 16+ GB in this case. Reading and copying smaller files is much 
faster (except with rsync, where it scores 25MB/s).

> > > What computer? (Laptop? Desktop? Server? Raspberry Pi? Age?)
> >
> > Supermicro A2SDi-4C-HLN4F, newish
>
> That mainboard has a Intel Atom C3558 soldered to it. That's a 2017 Atom with 
> 2,2 Ghz.

Yeah, you tell me. Supermicro uses what Intel provides, and there is no series 
4 Atom yet.

> I have no personal experience with Atom CPUs, so i can only generically say: 
> "not exactly build for speed".

It is built for its purpose, and it does it very well. There is no better 
workhorse at 16W.
> > > What "Buses"? ( a) Any modern "bus" is NOT saturated by those numbers. b) 
> > > All modern "buses" (Except USB, to some degree) are P2P, you can't even 
> > > connect 2 devices to the same bus. (Except USB, but there are usually 
> > > several controllers so you don't have to use same bus).)
> >
> > Supermicro CSE-M14TQC 4xSAS/SATA bay, connected with a CBL-SAST-0616(50cm) 
> > Mini-SAS HD to 4 SATA cable. The CSE receives the 4 sata cables, the 
> > mini-sas end is plugged on the main board.
>
> AFAICT each HDD is in effect connected to a separate channel, so no 
> contention there.

There is something odd happening there. If I run rsync across the network, I 
get full speed reading from the donor, saturated LAN link at 1Gbps (800/900 
Mbps), full speed writing from the recipient, and the job done in 2 hours. If I 
rsync from a local disk to a local disk, using the hardware above, then the 
same job takes 8 hours.

> > > With or without networking involved?
> >
> > no network involved

> > > What Filesystem? What mount-options?
> >
> > FFS2
>
> This mean either you are using a Flash Filesystem for a HDD, which would be 
> "odd".
> Or you are using a BSD-Type OS. I would guess FreeBSD?

This is BSD's Fast File System version 2.

> In both cases: No personal experience.

> I mainly use Linux Systems with XFS as a filesystem. I personally hadn't had 
> a problem saturating most storages for more than a decade.
> But i also use seperate Storage-types with different content. "Low AVG 
> filesize"-files i put on SSDs. And HDDs only get used for files with a 
> largish AVG filesize, mostly more than 10MB per file.
> And i also use "rsync --preallocate", so large files are stored "as 
> contiguosly as possible".

Interesting.

> > > AVG Filesize? Directory structure? Fragmentation?
> >
> > mixed
>
> That is what average means:
> Total number of files divided by total filesize. You have already determined 
> the total file size.
> Now you only need to: 

Re: RAM speedup

[Rupert Gallagher via rsync]

‐‐‐ Original Message ‐‐‐
On Sunday 28 June 2020 13:58, Matthias Schniedermeyer  wrote:

> On 27.06.2020 11:22, Rupert Gallagher via rsync wrote:
>
> > On Friday 26 June 2020 21:58, Rupert Gallagher via rsync 
> > rsync@lists.samba.org wrote:
> >
> > > Hello,
> > > As disks are slow and rsync reads and writes so much that for the bus 
> > > this is the equivalent of context switching galore, would it be possible 
> > > to use RAM as a buffer? Say, you have 10GB of spare RAM, rsync uses the 
> > > bus to its peak for reading 10GB, then again for writing it down. This 
> > > would be more efficient than lot of small read/write operations.
> > > Thank you
> >
> > Current task: rsync 752 GB
> > source disk
> > Writing speed: 77 MB/s
> > Reading speed: 97 MB/s
> > target disk
> > Writing speed: 117 MB/s
> > Reading speed: 99 MB/s
> > Actual time: 380 min (6.3 hours) to copy 648 GB
> > Actual speed: 28 MB/s (648/380 = 1.7 GB min =~ 1700MB min / 60 min = 28MB 
> > sec)
>
> Unfortunatly you left out every other detail.


> Complete rsync commandline?

/usr/local/bin/rsync --recursive --links --times --modify-window=1 --devices 
--specials --update --owner --group --perms --delete --delete-before 
--delete-excluded --exclude-from=/etc/excluded_from_backup.conf --numeric-ids 
--outbuf=Block --inplace --link-dest=/backup/latest/ /archive /backup


> What hardware? (From the numbers it is only clear that you seem to talk about 
> HDDs.)
> What HDDs?

source:
ST2000NX0403  sata hdd
Writing speed  : 117 MB/s
Reading speed  : 99 MB/s

destination:
ST5000LM000-2AN1 sata hdd
Writing speed  : 74 MB/s
Reading speed  : 89 MB/s

> What computer? (Laptop? Desktop? Server? Raspberry Pi? Age?)

Supermicro A2SDi-4C-HLN4F, newish

> What "Buses"? ( a) Any modern "bus" is NOT saturated by those numbers. b) All 
> modern "buses" (Except USB, to some degree) are P2P, you can't even connect 2 
> devices to the same bus. (Except USB, but there are usually several 
> controllers so you don't have to use same bus).)

Supermicro CSE-M14TQC 4xSAS/SATA bay, connected with a CBL-SAST-0616(50cm) 
Mini-SAS HD to 4 SATA cable. The CSE receives the 4 sata cables, the mini-sas 
end is plugged on the main board.



> With or without networking involved?

no network involved

> What Filesystem? What mount-options?

FFS2

rw,nodev,nosuid,softdep,noatime

> AVG Filesize? Directory structure? Fragmentation?

mixed

> Are you:
>
> -   Copying 1 752GB File(*)

no

> -   752 1GB Files

no

> -   10.000.000 78KB Files inside a directory-Tree with 10.000.000 Million 
> subdirectories

no

> -   100.000.000 7.8KB Files in 100.000.000 Million subdirectories.

no

> Personally my usual copying-speed for the "from local XFS formated HDD to 
> local XFS formated USB-3-HDD"-case is about 350GB/Hour (or about 100MB/s.), 
> and that has been the case for years.

I shall be so lucky...


> *:
> Even copying 2 different 752GB files can be quite a different monster 
> depending on file-fragmentation.
> Copying a heavily fragmented file (from a HDD) is slow, even when it is a 
> single big file.
> HDDs are very "sensitive" to sub-optimal usage, every 'seek' kills of 
> several ms where 0KB can be read/written.
> The worst-case performance (or IOPS) of a HDD is counted in KB/s(!!), if 
> you have to seek after every sector read or written.
>
> --
>
> Matthias
>



-- 
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-questions.html

Re: RAM speedup

[Rupert Gallagher via rsync]

On Friday 26 June 2020 21:58, Rupert Gallagher via rsync 
 wrote:

> Hello,
>
> As disks are slow and rsync reads and writes so much that for the bus this is 
> the equivalent of context switching galore, would it be possible to use RAM 
> as a buffer? Say, you have 10GB of spare RAM, rsync uses the bus to its peak 
> for reading 10GB, then again for writing it down. This would be more 
> efficient than lot of small read/write operations.
>
> Thank you


Current task: rsync 752 GB

source disk
Writing speed: 77 MB/s
Reading speed: 97 MB/s

target disk
Writing speed: 117 MB/s
Reading speed: 99 MB/s

Actual time: 380 min (6.3 hours) to copy 648 GB
Actual speed: 28 MB/s (648/380 = 1.7 GB min =~ 1700MB min / 60 min = 28MB sec)

Potential speed

Since both disks are on same bus,
first we saturate the bus when reading,
then we saturate the bus when writing.

reading time: 752 GB =~ 752000 MB / 97 MB/s =~ 7752 sec = 2.2 hours
writing time: 752 GB =~ 752000 MB / 117 MB/s =~ 6427 sec = 1.7 hours

In summary, the task could be completed in 4 hours instead of 8.

If the disks were on a different bus, and RAM would be refilled while writing 
on disk,
the task could be completed in 2 hours.



-- 
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-questions.html

RAM speedup

[Rupert Gallagher via rsync]

Hello,

As disks are slow and rsync reads and writes so much that for the bus this is 
the equivalent of context switching galore, would it be possible to use RAM as 
a buffer? Say, you have 10GB of spare RAM, rsync uses the bus to its peak for 
reading 10GB, then again for writing it down. This would be more efficient than 
lot of small read/write operations.

Thank you-- 
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-questions.html

Re: Rsync 3.1.3 released

[Rupert Gallagher via rsync]

zlib/inflate.c:1528:61: warning: shifting a negative signed value is undefined 
[-Wshift-negative-value]
if (strm == Z_NULL || strm->state == Z_NULL) return -1L << 16;
~~~ ^

 Original Message 
On 29 January 2018 1:23 AM, Wayne Davison via rsync  
wrote:

> Rsync 3.1.3 is now available for downloading.  This is a security, feature, 
> and bug-fix release.
>
> To see a full summary of the changes since 3.1.2, visit this link:
>
>   http://rsync.samba.org/ftp/rsync/src/rsync-3.1.3-NEWS
>
> You can download the source tar file and its signature from here:
>
>   http://rsync.samba.org/ftp/rsync/src/rsync-3.1.3.tar.gz
>   http://rsync.samba.org/ftp/rsync/src/rsync-3.1.3.tar.gz.asc
>
> See the rsync website for other downloads, including diffs, patches, etc.:
>
>   http://rsync.samba.org/
>
> ..wayne..-- 
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-questions.html