Re: update anonftpsync
- To: email@example.com
- Subject: Re: update anonftpsync
- From: Arnt Karlsen <firstname.lastname@example.org>
- Date: Sat, 1 Mar 2008 09:37:43 +0100
- Message-id: <email@example.com>
- In-reply-to: <20080229125747.GA25026@keid.carnet.hr>
- References: <20080221160134.GA11891@libra> <20080226134611.GA25476@keid.carnet.hr> <firstname.lastname@example.org> <20080228191924.GA21334@cetus> <email@example.com> <20080229040220.GA27032@cetus> <20080229125747.GA25026@keid.carnet.hr>
On Fri, 29 Feb 2008 13:57:48 +0100, Josip wrote in message
> On Thu, Feb 28, 2008 at 11:02:20PM -0500, Justin Pryzby wrote:
> > > ..how is then --del different from --delete-after when updating
> > > a Debian mirror, other than that one big ass batch at the end?
> > I think I was wrong about --delete-after; it really is needed.
> > Otherwise the *old* Packages.gz file will be referencing nonextant
> > .debs, which is the same situation that's trying to be avoided for
> > the new Packages.gz by running rsync twice.
> Exactly, there's a race condition window there. With users who are on
> a slow link (e.g. modem, ISDN, slow wireless/DSL), they might start
> downloading the old Packages file, churn at it for five or ten
> minutes, during which time you can also remove the file from disk
> (the rsync can renew everything), but Apache will keep serving it to
> them until their connection is done.
> After that, they unknowingly run apt-get upgrade which tries to get
> the previous revisions of packages, yet they get a bunch of 404s,
> because the server's rsync process is deleting the files. Then they
> run apt-get update again, and find no new changes (because the server
> isn't done deleting files yet), which leaves them puzzled.
> If we keep the old data files in place until the point where all
> indices are updated, we don't really help much in the way of
> eliminating the race condition, but we shorten its time and we
> eliminate the user confusion (because we're sure that their
> subsequent apt-get update will get the new indices).
> (Yet, my example isn't necessarily exactly applicable every time,
> because dak is known to have a setting which leaves the last few
> old .deb revisions in the pool even if they are obsolete. However,
> this can't be relied upon, so we still suggest some amount of
> leniency in the mirroring as well. If one's mirror server is low on
> free space, obviously they can't follow our suggestion, but it's
> still a decent default.)
..so, the way to do this, is run --delete-during on the pool/ tree
and --delete-after on everything else, to minimize mirror disk usage?
..and run --delete-after if I want a failsafe mirror and don't
care about mirror disk space?
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.