On 1 October 2010 04:30, Thomas Spuhler <[email protected]> wrote: > On Thursday, September 30, 2010 06:32:29 pm Olivier Thauvin wrote: >> Hi, >> >> I did started to contact some people to find Tier1 mirrors. One question >> come immediatelly: what will be the size of our mirror tree ? >> >> To have an idea I checked the mirror of the current Mandriva cooker and >> the result make me afraid. >> >> The current cooker tree (RPMS + installer only) is 88GB (SRPMS + i586 + >> x86_64). If I add 3 DVD iso (4GB each) I get around 100GB. >> >> This mean at the begining our mirror will be ~80 GB and in 3 years (1 >> release every 6 months) our tree size will be around 700GB ! >> >> 700GB is an huge size. I know anyone can buy a 1 TB hard drive for a >> small price, however this is not the way it works in real datacenter >> where people take care to the safety of data (RAID1 is two disk). And >> we have to think to future: what will be the size in 6 years ? >> >> The current full Mandriva mirror is more than 1,2 TB. >> >> So an immediate question come: should we try to reduce the size ? >> >> There are solutions, but they implies changes in our development >> process and have counter parts: >> - using hardlink between RPM: >> - can be done for noarch inside a release >> - no resiging packages from cooker to stable at release (rpm changes, >> any possible hardlink get broken) >> - do not push -debug: will bother others developers >> - removing old distro (having another tree for old): this usualy >> bother people having old distribution still working on some >> computers, 3 years is not a so long timelife >> >> So: >> - is this kind of size an issue ? >> - do we have to reduce it ? >> - do you have comments/idea about this state ? >> >> Regards. > Isn't the SVN that uses most of the space? Do we need to have everything back > to the beginning incl all releases? > > -- > Thomas >
IHMO, SVN (and SRPMS) are more important than binary packages, no point keeping a twig and killing the tree it came from, right? especially as SVN logs explain why every thing concerning a particular package was done in a certain way... -- Ahmad Samir
