From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Molenda To: Andrew Cagney Cc: Jim Kingdon , DJ Delorie , overseers@sourceware.cygnus.com Subject: Re: ftp mirrors Date: Sat, 30 Dec 2000 06:08:00 -0000 Message-id: <20000610093836.A25442@shell17.ba.best.com> References: <200006091545.LAA00938.cygnus.project.sourcemaster@envy.delorie.com> <3941CC03.B74B3373@cygnus.com> <20000610010132.A20997@shell17.ba.best.com> <394223B7.A1A849E9@cygnus.com> X-SW-Source: 2000/msg00634.html 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Molenda To: Andrew Cagney Cc: Jim Kingdon , DJ Delorie , overseers@sourceware.cygnus.com Subject: Re: ftp mirrors Date: Sat, 10 Jun 2000 09:39:00 -0000 Message-ID: <20000610093836.A25442@shell17.ba.best.com> References: <200006091545.LAA00938.cygnus.project.sourcemaster@envy.delorie.com> <3941CC03.B74B3373@cygnus.com> <20000610010132.A20997@shell17.ba.best.com> <394223B7.A1A849E9@cygnus.com> X-SW-Source: 2000-q2/msg00327.html Message-ID: <20000610093900.fa4nDPsW3lyDwezQ3uAh49by9LCjQzoOPLFFyoX5ur4@z> 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