public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Jason Molenda <jason-swarelist@molenda.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Jim Kingdon <kingdon@redhat.com>, DJ Delorie <dj@delorie.com>,
	overseers@sourceware.cygnus.com
Subject: Re: ftp mirrors
Date: Sat, 30 Dec 2000 06:08:00 -0000	[thread overview]
Message-ID: <20000610093836.A25442@shell17.ba.best.com> (raw)
In-Reply-To: <394223B7.A1A849E9@cygnus.com>

On Sat, Jun 10, 2000 at 09:17:11PM +1000, Andrew Cagney wrote:

> That isn't what I'm thinking of.  given a gzip file, rsync has
> effectivly random data.  

Right.

> Given the file uncompressed and rsync can
> recognize internal sections.  

??  Rsync recognizes blocks of data.  It doesn't interpret the
syntax of a .c file, run an SGML parser on an .html file, or try
to parse the English sentences in a .txt file.  A block of random
data and a block of human-readable data are little different to
rsync.

> Tar balls, for instance change very
> little, however because they are compressed, rsync can't see that.

How is a tarball any different from any other file?
How often does someone modify an existing tarball, anyway?
Rsync will run a checksum or timestamp check on the tarball, see
that the checksum of the server version matches that of the client
version, and move on.

Are you making this all up on your own - assuming that there is a
problem - or is there some actual evidence of a problem?  I don't
mean to be harsh, but I seem to be engaged in an intellectual
discussion of the tone "I bet rsync is slow doing foo and we should
change how we do things.  Someone should prove to me otherwise."

Jason

WARNING: multiple messages have this Message-ID
From: Jason Molenda <jason-swarelist@molenda.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Jim Kingdon <kingdon@redhat.com>, DJ Delorie <dj@delorie.com>,
	overseers@sourceware.cygnus.com
Subject: Re: ftp mirrors
Date: Sat, 10 Jun 2000 09:39:00 -0000	[thread overview]
Message-ID: <20000610093836.A25442@shell17.ba.best.com> (raw)
Message-ID: <20000610093900.fa4nDPsW3lyDwezQ3uAh49by9LCjQzoOPLFFyoX5ur4@z> (raw)
In-Reply-To: <394223B7.A1A849E9@cygnus.com>

On Sat, Jun 10, 2000 at 09:17:11PM +1000, Andrew Cagney wrote:

> That isn't what I'm thinking of.  given a gzip file, rsync has
> effectivly random data.  

Right.

> Given the file uncompressed and rsync can
> recognize internal sections.  

??  Rsync recognizes blocks of data.  It doesn't interpret the
syntax of a .c file, run an SGML parser on an .html file, or try
to parse the English sentences in a .txt file.  A block of random
data and a block of human-readable data are little different to
rsync.

> Tar balls, for instance change very
> little, however because they are compressed, rsync can't see that.

How is a tarball any different from any other file?
How often does someone modify an existing tarball, anyway?
Rsync will run a checksum or timestamp check on the tarball, see
that the checksum of the server version matches that of the client
version, and move on.

Are you making this all up on your own - assuming that there is a
problem - or is there some actual evidence of a problem?  I don't
mean to be harsh, but I seem to be engaged in an intellectual
discussion of the tone "I bet rsync is slow doing foo and we should
change how we do things.  Someone should prove to me otherwise."

Jason

  parent reply	other threads:[~2000-12-30  6:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200006091545.LAA00938.cygnus.project.sourcemaster@envy.delorie.com>
2000-12-30  6:08 ` Jim Kingdon
2000-06-09 14:53   ` Jim Kingdon
2000-12-30  6:08   ` Andrew Cagney
2000-06-09 22:05     ` Andrew Cagney
2000-12-30  6:08     ` Jason Molenda
2000-06-10  1:02       ` Jason Molenda
2000-12-30  6:08       ` Jason Molenda
2000-06-10  1:08         ` Jason Molenda
2000-12-30  6:08       ` Andrew Cagney
2000-06-10  4:19         ` Andrew Cagney
2000-12-30  6:08         ` Jason Molenda [this message]
2000-06-10  9:39           ` Jason Molenda
2000-12-30  6:08         ` Andrew Cagney
2000-06-10 18:03           ` Andrew Cagney
2000-12-30  6:08           ` Jason Molenda
2000-06-10 23:55             ` Jason Molenda
2000-12-30  6:08             ` Jim Kingdon
2000-06-11  8:24               ` Jim Kingdon
2000-12-30  6:08               ` Jason Molenda
2000-06-11 15:08                 ` Jason Molenda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000610093836.A25442@shell17.ba.best.com \
    --to=jason-swarelist@molenda.com \
    --cc=ac131313@cygnus.com \
    --cc=dj@delorie.com \
    --cc=kingdon@redhat.com \
    --cc=overseers@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).