[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A success story with apt and rsync

Hash: SHA1

On Sunday 06 July 2003 11:27, Goswin Brederlow wrote:
> Koblinger Egmont <egmont@uhulinux.hu> writes:
> > Hi,
> >
> > >From time to time the question arises on different forums whether it is
> >
> > possible to efficiently use rsync with apt-get. Recently there has been a
> > thread here on debian-devel and it was also mentioned in Debian Weekly
> > News June 24th, 2003. However, I only saw different small parts of a huge
> > and complex problem set discussed at different places, I haven't find an
> > overview of the whole situation anywhere.
> ...
>  Lets
> summarize what I still remember:
> 2. most of the time you have no old file to rsync against. Only
> mirrors will have an old file and they already use rsync.

/var/cache/apt/ ?

> 4. (and this is the knockout) rsync support for apt-get is NO
> WANTED. rsync uses too much resources (cpu and more relevant IO) on
> the server side and a widespread use of rsync for apt-get would choke
> the rsync mirrors and do more harm than good.

When I was looking into this I heard about some work into caching the rolling 
checksums to eliminate server load. I didn't find any code.

> Doogie is thinking about extending the Bittorrent protocol for use as
> apt-get method. I talked with him on irc about some design ideas and
> so far it looks realy good if he can get some mirrors to host it.

Sounds interesting.  bittorrent allocates people to peer off in a round-robin 
fashon, which is really stupid.  If two people have similar IPs they should 
make a better peer.

> Via another small extension rolling
> checksums for each block could be included in the protocol and a
> client side rsync can be done. (I heard this variant of rsync would be
> patented in US but never saw real proof of it.)

Likewise on both counts.

Version: GnuPG v1.2.1 (GNU/Linux)


Reply to: