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. Thanks, Peter _______________________________________________ mirrorbrain mailing list Archive: http://mirrorbrain.org/archive/mirrorbrain/ Note: To remove yourself from this mailing list, send a mail with the content unsubscribe to the address mirrorbrain-request_at_mirrorbrain.orgReceived 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