[CentOS-mirror] [CentOS-devel] irc meeting today re: 5.6/6.0

Tue Jan 18 16:16:39 UTC 2011
Jim Kusznir <jkusznir at gmail.com>

My $0.02:

I fully concur with #2.  I'm not sure how to functionally deploy this
unless perhaps the 6.0 tree is sync'ed on the same filesystem but
outside the rsync tree, then a script is run on all the master mirrors
at the right time (at/cron job?) that moves the 6 tree into its proper
place.  There's probably a better way; I only run one mirror, not a
network of mirrors.

With respect to mirror bandwidth, I know I have a lot, and we just
upgraded ours.  That said, I have long thought that it makes more
sense to distribute iso's via torrents for the initial download.
"Dangling a carrot" to encourage users to use torrents intead of
mirror bandwidth might be good; making the iso available 24hrs in
advance via torrents will help to distribute the download more so, and
help show torrents have valid, legal, real-world application :)  Of
course, in that case I'd also be hosting a torrent seed or two from my

I don't think the original post mentioned anything about seeding the
mirrors from the torrent iso; that seems like its unnecessary,
error-prone, and a lot of work.  I think it was more to address the
above: help move end user downloads off the mirror server network
during a peak download event.  Again, I'm for it, but I would say
something like "release 24hrs early via torrents" would be a good
thing.  That would give the mirror servers a bit more time to download
and sync.  Perhaps the tree without iso's should be sync'ed on the
mirrors first, with the iso's available only via torrents for the
first 24-48 hrs....

In any case, I suggest/expect that the torrent seeds/downloads would
not effect mirror operators or the servers themselves unless the admin
decided to also seed the torrent.  Of course, all mirrors would
benefit by offloading those users that "have to have it as soon as its

Also, perhaps this would be a good time for the new mirror management
system?  Something to more intelligently distribute downloads?  I know
most of the downloads from our large university don't use the mirror
server located on the university network, but download from other
systems while our mirror server is busily serving off-campus
requests.....  Such a system may also be able to distribute download
requests more proportionately to the mirror server's capabilities.
I've noticed often when I just use the round robin DNS, often my
download is very slow on release day, while I can hit 2-4 choice
mirrors and get very fast downloads.


On Sun, Jan 16, 2011 at 4:00 AM, Nyamul Hassan <nyamul at gmail.com> wrote:
>> 2) We need to be thorough in the release process. It wastes time and
>>    bandwidth for mirrors to download content from one master, only to have
>>    the next cycle hit a different master that doesn't have the new content
>>    (at which point the mirror deletes the content it had downloaded).
> This is probably the most pressing issue.  If somehow, all the masters can
> be synced at first, before releasing to the public, that would greatly
> reduce the gripes most mirror admins have.
>> 3) Trying to pre-load a mirror from the ISOs is a manual process, it's
>>    error-prone, and it's a pain in the butt. Mixed with the ping-pong
>>    effect, it's not worth the time nor the trouble. Most mirrors won't get
>>    the new content until they get it from rsync.
> Yes, and that is why I am not very fond of the "torrents" idea.  I would
> prefer to not have all the mirrors go through some manual work to update
> their mirrors.  Once again, the "ping pong" is a remnant of "out of sync"
> masters, as described in #2 above.
>> As long as seeding a 95% torrent doesn't delay the synchronization of the
>> mirror network or delay the official release, I have no argument against
>> it. Don't delay the mirror network to aid the torrents.
>> In the matter of 5.6 versus 6.0, I'll echo sentiments already expressed.
>> There are 5.5 machines in production today. Those machines aren't getting
>> updates until 5.6 comes out. Nobody is depending on the 6.0 tree yet.
>> Don't delay 5.6 for 6.0.
> I would agree on this one, that 5.6 is more relevant as of now, than 6.0.
> Regards
> _______________________________________________
> CentOS-mirror mailing list
> CentOS-mirror at centos.org
> http://lists.centos.org/mailman/listinfo/centos-mirror