From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20101129/001489.html | 123 ++++++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101129/001489.html (limited to 'zarb-ml/mageia-dev/20101129/001489.html') diff --git a/zarb-ml/mageia-dev/20101129/001489.html b/zarb-ml/mageia-dev/20101129/001489.html new file mode 100644 index 000000000..16016fbf1 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001489.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] Mirror layout, round two + + + + + + + + + +

[Mageia-dev] Mirror layout, round two

+ Olivier Thauvin + nanardon at nanardon.zarb.org +
+ Mon Nov 29 04:32:07 CET 2010 +

+
+ +
* Maarten Vanraes (maarten.vanraes at gmail.com) wrote:
+> Op maandag 29 november 2010 01:24:42 schreef Michael scherer:
+> > So if we decide "mirrors will not handle the load, so we need to split
+> > games", then we should also say "mirrors will not handle the load, so we
+> > need to do less iso/offer to not mirror debug/offer to not mirror some
+> > architecture", and we end with a non consistent network of mirror, with
+> > lots of complexity on our side to handle the possible choice made by
+> > mirrors. I am not sure that users
+
+The solution is quite simple: do not give the choice.
+
+For exemple, I am completly unable to know which part of Fedora or
+Centos i can exclude, so I exclude nothing (espcially since none of this
+distro said something can be excluded).
+
+> > will truly benefit from this. And I am sure that we will not benefit from
+> > the complexity.
+> > 
+> > If the space is a issue ( and I think that's one of the main one ), then we
+> > should decide based on metrics. Ie, we plan to have no more than X% growth
+> > in mirror size for 1 year. If we hit some soft limit, then we investigate
+> > and decide ( ie, stop adding big backport, stop adding new package, etc ).
+
+The space is an issue, but the distro size is increasing like everything
+and like all distro. Disk size is also growing.
+
+The problem is the size of the global tree, not the size of a single
+distro. I expect a 700 GB for Mageia, the distribution is far less than
+that.
+
+> 
+> I agree with you partly (mostly on the basis that mirror setup should be 
+> primarily for mirror admins), however:
+>  - some of those big packages are pretty much core
+>  - and a big core repos is having a big hdlists as well; and you should take 
+> into consideration that some people have regular phone line internet.
+>  - i'm not entirely sure that mirror admins would like the overflow idea:
+>     - if you're a small public mirror (ie: storage size), you would not mirror 
+> the overflow; however some big packages would be pretty essential. seperating 
+> extra (unmaintained pacakages); and games would seem easier; also on the 
+> following up side; (ie: when problems arise); also a point is what about those 
+> big packages and their dependencies (or rather other packages which depend on 
+> it).
+
+If you're maintaining a mirror you should first take care about the
+ressources need by each distro you host, and small mirror won't probably
+host mageia.
+There enough big mirrors around the world able to host us to not
+encourage small one to mirror us with bad practices, IMHO.
+
+Obviously, we (mirrors admin) have always the same question before
+hosting a new tree: "how many space do you need" and "how many bandwidth
+will be used".
+
+-- 
+
+Olivier Thauvin
+CNRS  -  LATMOS
+♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 197 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20101129/2a00408a/attachment.asc>
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1