[mirror-admin] Fedora 9 Preview syncing now

David Timms dtimms at iinet.net.au
Wed Apr 23 10:55:46 EDT 2008


Matt Domsch wrote:
> On Mon, Apr 21, 2008 at 04:26:21PM -0400, Jesse Keating wrote:
>> On Sat, 2008-04-19 at 17:11 -0400, Jesse Keating wrote:
...
> As this is the first time we've tried the Tier 0 -> 1 -> 2 mirroring,
> please pay attention to how well this works for you (delay between
> when Jesse made the bits available and when you finally had them; ease
> of getting the bits; bandwidth you were able to use in getting the
> bits).  I'd like to know that all went well for you, as well as any
> particular problems you may have encountered, so we can address them
> before the full release of F9 on 13-May.
> 
> For the iBiblio Tier 0 mirror, it was able to pull the content from
> Red Hat directly at about 100Mbit/sec, total download time was right
> at 2 hours; of the 47GB total, 33GB were new ISOs, 14GB was able to be
> hardlinked from the development/ tree so not transferred again.

Compare to this an enduser downloader - and it did take a bit of effort 
first up:
I have a rawhide server that has a heap of packages installed, probably 
1:1 within dvd.iso:everything packages. This gets yum updated everyday 
{think rawhide rsync that the mirror's do}.

0h:00 -> 4h:00 {0->3.1%} : ran the torrent for a 4 hours, and requested 
someone who has the full iso run iso-info to find the structure of the 
dvd iso. This information is stored within about the first 1MB of the iso.

4h:00 -> 4h:07 {->29.8%} : since bittorrent tries to distribute 
downloads, I was able to get only a partial directory listing. Used a 
python script I wrote last year to partially build the recently released 
Preview iso by inserting just some of the rpms I had downloaded already. 
This took about 7mins to effectively insert the correct data at the 
correct part of the iso.

4h:07 -> 8h:00 {->37.28%} : recheck and continue the torrent overnite 
{getting 10kB/sec dl, 40kB/sec ul}.

8h:00 -> 8h:10 {->62.1%} : a fedora user send me a complete iso-info 
dump {about 200kB}. inserted the already downloaded rpms into the iso image.

8h:10 -> 15h:00 {->66.7%} : recheck and continue the torrent

15h:00 -> 15h:15 {->93.2%} : wrote a script to extract the file names 
from the dvd iso-info, and convert it to an rsync include file. rsynced 
from rawhide {nearest rawhide mirror} only the items included on the 
iso. inserted those files into the image. {actually the time taken to 
run the insert is bigger each time because it reinserts all the 
pre-downloaded parts again}.

15h:15 -> 20h:00 {->100%} : recheck and continue the torrent 'til complete.

Originally, bittorrent was saying about 7days to complete the download. 
  By inserting about 71% of the size of iso {not live media} that Matt 
mentions, is it worth developing such techniques to be used at the 
mirror level, and hence save serious bandwidth for mirrors who mirror 
rawhide {I don't know the percentage who do}, or the pre-release iso 
series ?
While jigdo does this, it's metadata file is huge in comparison 250KB -> 
250 MB or more, and in my experience has been slow and sometimes fails 
to complete at all {pyjigdo}.

Could it be worked into the mirror sites normal automated processes in 
the future ?

One thing I hadn't considered is how different is an unsigned rawhide 
rpm to it's other wise identical signed release ? Does rsync make good 
use of the similarity ?

--


More information about the Mirror-admin mailing list