[Mageia-dev] Mirror tree structure

Fri Oct 22 04:48:31 CEST 2010

Romain d'Alverny a écrit :
+> On Wed, Oct 20, 2010 at 18:34, Olivier Thauvin
+> <nanardon at nanardon.zarb.org>  wrote:
+>    
+>> Now come the question: "what is a valid mirror ?", eg, what a mirror
+>> should have as file to be valid ?
+>>      
+> Not sure if we discussed in depth MirrorBrain
+> (http://www.mirrorbrain.org/ ) for managing mirrors index and
+> redirections.
+>
+> If we were going to use it, could we, for instance, leave mirrors some
+> liberty to mirror what branch they want (with some guidances and
+> preferences of course) and let our MirrorBrain instance check and
+> build the list of valid mirrors for the file actually requested?
+>
+> This, provided that _consistent_ branches of the tree are mirrored,
+> and not only a file here, a file there.
+>
+> On one hand, this would introduce at least to other things to check:
+>   - having enough distributed mirrors that map the whole tree;
+>   - having download/install tools take this into account.
+>
+> On the other hand, this could allow more mirrors to take part in this,
+> in that it may require less storage space and less bandwidth usage.
+>    
+This is an excellent idea, at least to some degree.
+Many users (like myself) like to download ISOs, which like the release 
+repositories, will change every 6 months (or whatever the release period).
+Otherwise they remain static, which means no maintenance for the mirror 
+sites.
+These elements tend to have relatively large space requirements.
+As well, they would have a very large demand (bandwidth) at release 
+time, to lessen considerably afterwards.
+
+The update/backport/testing/debug repositories (or whatever Mageia will 
+call them) are considerably smaller, but in constant flux, thus 
+requiring regular updates on the mirror sites.
+These transient repositories would tend to have a relatively constant, 
+lower bandwidth demand.
+
+So at least static/transient would be a natural separation.
+As long as the division is by Mageia's repositories, it should be 
+workable if mirrors select repositories on other bases.
+
+I think it would be useful to keep the update/backport repositories 
+together, since they are likely to be used together, and maybe all 
+transient repositories.
+Having the ISOs on separate mirrors should cause no problem, as users 
+are likely to download an ISO by itself, one at a time.
+
+> It's not the only reason to use MirrorBrain anyway, but I wondered if
+> this could be a complementary reason.
+>
+> Not sure, insights welcome.
+>    
+After a quick look at the MirrorBrain features page, I say let's get it.
+
+There is a problem with the current Mandriva mirror system, using Rpmdrake.
+I'm in Montréal, and the nearest Mandriva mirror is not very reliable.  
+It also allows only one direct download at a time.  So when I download 
+ISOs, I go directly to another mirror, use multiple connexions, to 
+download the ISO relatively fast, which is fine.
+
+For updates and incremental downloads it is much easier to use Rpmdrake.
+However, often, after having selected a package, I get an error message 
+saying the package could not be downloaded because of a problem with the 
+mirror site.
+(I suspect that usually the site is just not in sync.)
+
+MirrorBrain seems to be the perfect solution for this problem, as well 
+as dealing with partial mirrors.
+
+Interestingly, if for some reason a mirror site cannot carry a 
+particular package because of restrictions imposed by the country where 
+it is located, MirrorBrain will be able to cope.  So that simplifies the 
+problem of dealing with legislative/copyright/patent restrictions as well.
+
+So at least 3 reasons to get MirrorBrain :)
+> Cheers,
+>
+> Romain
+>    
+
+my 2 cents
+
+- André (andre999)
+
+