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
