[CentOS] Need help to fix bug in rsync

Thu Mar 26 06:48:06 UTC 2020
Simon Matter <simon.matter at invoca.ch>

> I appreciate the reply - it keeps me from wondering "is there something I
> should be concerned about?".  We use a co-location facility where we pay
> for bandwidth utilization so it's still an issue.

Hi,

You are right, bandwidth always costs, always.

Who pays for it can differ a lot, but there is always someone who pays.

It can be an individual, a company, the tax payer, whoever, but bandwidth
is never free.

Thanks,
Simon

>
> ________________________________
> From: CentOS <centos-bounces at centos.org> on behalf of Pete Biggs
> <pete at biggs.org.uk>
> Sent: Wednesday, March 25, 2020 1:32 PM
> To: centos at centos.org <centos at centos.org>
> Subject: [EXTERNAL] Re: [CentOS] Need help to fix bug in rsync
>
>
> Harriscomputer
>
> Leroy Tennison
> Network Information/Cyber Security Specialist
> E: leroy at datavoiceint.com
>
>
> [cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]
>
>
> 2220 Bush Dr
> McKinney, Texas
> 75070
> www.datavoiceint.com<http://www..com>
>
>
> This message has been sent on behalf of a company that is part of the
> Harris Operating Group of Constellation Software Inc.
>
> If you prefer not to be contacted by Harris Operating Group please notify
> us<http://subscribe.harriscomputer.com/>.
>
>
>
> This message is intended exclusively for the individual or entity to which
> it is addressed. This communication may contain information that is
> proprietary, privileged or confidential or otherwise legally exempt from
> disclosure. If you are not the named addressee, you are not authorized to
> read, print, retain, copy or disseminate this message or any part of it.
> If you have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the message.
>
>
>
>
>
> On Wed, 2020-03-25 at 19:15 +0100, Simon Matter via CentOS wrote:
>> > On Wed, 2020-03-25 at 14:39 +0000, Leroy Tennison wrote:
>> > > Since you state that using -z is almost always a bad idea, could you
>> > > provide the rationale for that?  I must be missing something.
>> > >
>> > I think the "rationale" is that at some point the
>> > compression/decompression takes longer than the time reduction from
>> > sending a compressed file.  It depends on the relative speeds of the
>> > machines and the network.
>> >
>> > You have most to gain from compressing large files, but if they are
>> > already compressed, then you have nothing to gain from just doing
>> small
>> > files.
>> >
>> > It obviously depends on your network speed and if you have a metered
>> > connection, but does anyone really have such an ancient network
>> > connection still these days - I mean if you have fast enough machines
>> > at both ends to do rapid compression/decompression, it seems unlikely
>> > that you will have a damp piece of string connecting them.
>>
>> I really don't understand the discussion here. What is wrong with using
>> -z
>> with rsync? We're using rsync with -z for backups and just don't want to
>> waste bandwidth for nothing. We have better use for our bandwidth and it
>> makes quite a difference when backing up terabytes of data.
>
> I don't really care if you use -z, but you asked for the rationale, and
> I gave you it. I'm not telling you what you should do.
>
> I'll try and make it simpler - if rsync takes 1 second to compress the
> file, then 1 second to decompress the file, and the whole transfer of
> the file takes 11 seconds uncompressed vs 10 seconds compressed, then
> dealing with file takes overall 12 seconds compressed, vs 11 seconds
> uncompressed. It's not worth it.
>
> But as I said it depends on your network and your machine speeds.  It's
> up to you to decide what is best in your own situation.
>
> P.
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>