Using zsync for .deb downloads.. misuse of --rsyncable

[Paul Sladen]

On Fri, 17 Jul 2009, Steve Langasek wrote:
> On Fri, Jul 17, 2009 at 05:11:14PM +0300, Lars Wirzenius wrote:
> > pe, 2009-07-17 kello 12:20 +0100, Matt Zimmerman kirjoitti:
> > > On Tue, Jul 14, 2009 at 07:19:31PM +0300, Lars Wirzenius wrote:
> > > > * rsyncable: This makes it easier for zsync to do magic things with gzip,
> > rsyncable: just under 1%. rsyncable3: about 18%.

When zsync cannot find some bytes locally, it downloads the "sector"
containing the required range of literal data.

If the sectors are smaller, finer download granularity can be achieved.

Creating sector divisions based on a rolling total of the last 4k bytes
(--rsyncable) being leads to sectors that are somewhat, urm, random in
frequency and have a 4096^-1 chance of actually aligning with any useful
checksum being used for matching detection.

That --rsyncable provides zsync with finer granularity is a coincidence and
is a quite suboptimal method of doing so.

> > Thus, using --rsyncable should be doable for the CD, but
> > re-compressing things with gzip instead of lzma or bzip2 is not.

Bzip2 files already provide sector-based access at a default granularity of
900kB (recompressing with 100kB sector sizes _would_ give finer
granularity).

> Over a 700MB CD, 1% is 7MB.  That amounts to a full language dropped

Package compression can be optimised for random access, or for minimum
package size, or for minimum whole-CD size, or for minimum (re-)compression
time, or for minimum (re-)compression memory overhead---but not all five.

Currently the post-encoding signing method requiries picking one only.

	-Paul
-- 
Why do one side of a triangle when you can do all three.  Somewhere, GB.