Re: deb diff format (debiff) proposal
On Sun, Dec 03, 2000 at 10:34:15PM +0100, Tim Jansen wrote:
> On Sun, Dec 03, 2000 at 02:24:01PM -0600, Adam Heath wrote:
> > All mirrors will still have to store the latest version of a deb. This is in
> > case the end machine has an older version of that package, that is out of
> > range of the .debiff.
> > They will also have to store M revisions(or N old days), and this could
> > quickly bloat.
> > Is there an limit as to how small the .debiff file needs to be, before storing
> > a new full .deb would be beneficial?
>
> Yes. You dont have to store the older debs, you only need the two last
> revisions to build a chain of diffs. This means that a user with an older version has
> to download one extra-diff for each revision that he skipped.
> Old diffs are not beneficial when the sum of the size of all stored diffs is
> over a certain limit, say 75% of the latest deb. This would still almost double
> the needed storage, but it could also reduce the required bandwidth of the
> mirrors significantly.
Yes.
It's not such a stupid idea, at all.
Storage is cheap, and getting cheaper all the time. I would have
thought that, for the typical debian mirror provider, of the two
resources they are donating, bandwidth is fairly likely to be the more
expensive.
Concretely, the debian archive is, what, comfortably within 40G. 40G
of storage costs about 100 quid here in the UK. Presumably less in
the states. That kind of money is nothing for most mirror providers.
OTOH, the bandwidth cost of a debian mirror could be many times that,
per month.
The .debiff system doesn't require mirrors to run intelligent software
--- ftp-master can take care of building the .debiffs. Other mirrors,
just mirror.
Indeed, ftp-master could reasonably easily provide two separate views
of the package tree, one with .debiffs and one without them. Then
mirrors could choose which view to mirror.
I think this idea needs more consideration before being dismissed out
of hand.
Jules
Reply to: