Re: Too few up-to-date CD image mirrors
On Mon, 2 Dec 2002, Josip Rodin wrote:
> On Mon, Dec 02, 2002 at 01:08:51PM +0100, Mattias Wadenstein wrote:
> > Yes, but jigdo is more hassle for the end users. Sure, it is a waste of
> > bandwidth, but if we didn't have bandwidth to "waste", we wouldn't run a
> > debian[-cd] mirror do begin with. You have a tradeoff there between what
> > is convenient for users and what is an effective use of our mirroring
> > resources.
> > But then, the mirror admins that voice their opinions here are those that
> > have already stated that they would rather have isos available.
> Yep, that's quite a valid argument. I also have images on my mirror because
> I do have the bandwidth, and if it'll help a bunch of users, it's probably
> worth it, so I keep them.
> The thing is, it appears that bandwidth is not such a commodity in the US ;)
> and all of our servers that have the disk space -- saens, raff, gluck -- are
> there. debian.hands.com, which is more-or-less our server (it's listed at
> machines.cgi but it's still Phil's machine) barely has the space for the
> stuff that's already on it, and none of the others seem to have space either.
Well, then the US users will just have to download them from over here? :)
> We should probably think about getting another few drives into the new
> syncproxy.eu for this...
Well, just one more 120 gig ide drive would be enough to add to that raid5
set, I think. I'll take a look at it. Need to get that machine installed
and so on too.
> > > But then, we already have a bunch of mirrors that do have images, so
> > > _something_ needs to be done to bring back the consistency.
> > Yes. A restricted rsync access to main mirrors would be good enough if we
> > don't want cdimage.d.o (or cdimage.us) to waste too much bandwidth. Just
> > so that once we have built the images with jigdo we can rsync the
> > directory structure against an official structure.
> Hmm. One thing, though, why keep the images locked on that machine just for
> a sync that happens every few months? Plus the administrative overhead of
> giving out accounts.
Because it is hell to try and mirror the images at release time when the
master machine is overloaded with a gazillion end users trying to download
it. And since other mirrors can't get to the images to mirror, more end
users end up at the master site.
Having the root of the tree hidden from public access is a good thing when
it comes to mirroring structures.
The administrative overhead isn't that bad, I'd guess at 10-30 accounts
that change very seldom.