Re: [mirrorbrain] ToDo for upcoming 2.13.0 release

From: Peter Poeml <>
Date: Wed, 5 May 2010 22:32:16 +0200
On Wed, May 05, 2010 at 01:13:58PM -0400, Cory Fields wrote:
> Agreed on the hashes cleanup. This should be done before any stable
> release that implements hashes in the db to eliminate the need for too
> much backwards thinking, as most will be starting from a clean slate.
> Perhaps you could eliminate all previous stale hash logic completely,
> and simply suggest that users clear the table first. Or maybe I'm
> overthinking since non-existent files would be cleared anyway.
> As for on-disk hashes, is there any valid reason to leave them on? Imo
> it makes sense to deprecate the option (off by default, stored in the
> db instead) for a few releases and see if anyone screams.

It's all thought out to allow for a smooth upgrade that doesn't
interrupt anything. So far, hashes exist only on-disk. When upgrading to
2.13.0, the necessary database table is created once the "mb" tool runs
(usually once a minute, for the mirrorprobe). Once the Apache module is
upgraded, it'll start looking for hashes. When the new database table
doesn't exist, it'll not be able to compile the database queries upon
forking a child. Hence, when updating the RPM packages, the post script
also runs the "mb" tool right away, so that the tables are created as
soon as possible.

(I need to figure out how to implement the same for Debian packages.)

Furthermore, while Apache will look into the database for hashes, it'll
also look on disk (for the current hash files) if the database doesn't
contain hashes. This means that hashes inside v3 Metalinks (as
implemented in the past) will continue to work during the migration
period, without interruption. In other contexts as v3 Metalinks, the
hashes on disk are not relevant (they weren't used for anything else).

While the hashing tool will store hashes both locations (db and files),
Apache will always prefer the database. So in principal, we could switch
off file storage. We might also keep it for some time, just in case
somebody has to mix packages.


mirrorbrain mailing list

Note: To remove yourself from this mailing list, send a mail with the content
to the address
Received on Wed May 05 2010 - 20:32:19 GMT

This archive was generated by hypermail 2.3.0 : Mon Aug 30 2010 - 18:32:11 GMT