[mirror-admin] Seeding newkeys with old content?

[Axel Thimm]

On Sat, Sep 06, 2008 at 02:26:03PM -0400, Chuck Anderson wrote:
> On Sat, Sep 06, 2008 at 08:24:30PM +0300, Axel Thimm wrote:
> > On Sat, Sep 06, 2008 at 11:51:15AM -0400, Chuck Anderson wrote:
> > > On Sat, Sep 06, 2008 at 10:44:32AM +0200, Adrian Reber wrote:
> > > > On Sat, Sep 06, 2008 at 08:34:46AM +0300, Axel Thimm wrote:
> > > > > does it make sense to seed the new rpms with the old signed ones?
> > > > > Would rsync note the change of a few bytes (the lead-in/out) and could
> > > > > it save the sync from redownloading the contents? Did anyone give it a
> > > > > test?
> > > > 
> > > > Doing cp -al before running rsync helps a lot on my side.
> > 
> > I'm trying this, still syncing.
> > 
> > > Excellent.  Can the master .newkey directories please start out as a 
> > > hardlinked tree of the original directories for a few days before 
> > > pushing out the re-signed content?
> > 
> > That's impossible, the files *are* different. cp -al is just for a
> > faster seeding, it wouldn't make an rsync difference if it were w/o
> > the -l.
> 
> Well the idea would be to have the master do cp -al from x to x.newkey 
> everywhere, let the mirrors sync that with rsync -H which won't 
> actually download anything--just hardlink the content.  Then after a 
> day or two, replace those hardlinked files on the master with the 
> actual new files.  Then the next rsync -H the mirrors do will only 
> download the tiny parts of the files that changed due to the new 
> signatures.
> 
> Granted, this does create a problem for those who use rsync without 
> -H, or FTP/HTTP to mirror.  They will end up downloading everything 
> twice.  Perhaps we should require mirrors to use rsync with -H.

The true issue here is that you would have to wait for the hardlinks
to be created on the mirrors for populating the master with the
changed content. The cp -a(l) on the mirror side is a better approach
as it gives you te best of both worlds (fast sync, early updates).
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mail.ale.org/pipermail/mirror-admin/attachments/20080906/c4466f35/attachment.bin 
-------------- next part --------------
--