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 servers.... 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 released". 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. --Jim 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 > HASSAN > _______________________________________________ > CentOS-mirror mailing list > CentOS-mirror at centos.org > http://lists.centos.org/mailman/listinfo/centos-mirror > >