Return-Path: <gentoo-releng-return-43131-arch-gentoo-releng=gentoo.org@lists.gentoo.org>
Delivered-To: lists.gentoo.org-arch-gentoo-releng@lists.gentoo.org
Received: (qmail 21102 invoked from network); 22 Jun 2004 20:53:57 +0000
Received: from smtp.gentoo.org (156.56.111.197)
  by lists.gentoo.org with AES256-SHA encrypted SMTP; 22 Jun 2004 20:53:57 +0000
Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org)
	by smtp.gentoo.org with esmtp (Exim 4.34)
	id 1BcsHA-0006oN-1G
	for arch-gentoo-releng@lists.gentoo.org; Tue, 22 Jun 2004 20:53:52 +0000
Received: (qmail 9974 invoked by uid 89); 22 Jun 2004 20:53:51 +0000
Mailing-List: contact gentoo-releng-help@gentoo.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:gentoo-releng@gentoo.org>
List-Help: <mailto:gentoo-releng-help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-releng-unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-releng-subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-releng.gentoo.org>
Reply-To: gentoo-releng@lists.gentoo.org
X-BeenThere: gentoo-releng@gentoo.org
Delivered-To: mailing list gentoo-releng@lists.gentoo.org
Received: (qmail 6720 invoked from network); 22 Jun 2004 20:53:51 +0000
Date: Tue, 22 Jun 2004 20:56:02 +0000
From: Kurt Lieber <klieber@gentoo.org>
To: gentoo-releng@lists.gentoo.org
Message-ID: <20040622205602.GG27818@mail.lieber.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="gDGSpKKIBgtShtf+"
Content-Disposition: inline
X-GPG-Key: http://www.lieber.org/kurtl.pub.gpg
User-Agent: Mutt/1.5.6i
Subject: [gentoo-releng] space allocation for releases on the mirrors

--gDGSpKKIBgtShtf+
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

In order to get a better handle on space utilization for our mirrors, I'm
going to put in a mostly-firm-but-somewhat-flexible cap on overall space
used for each release.  Taking a look at the amount of space used for each
arch in 2004.1, we have:

2.9G    ./ppc/2004.1
4.5G    ./x86/2004.1
1.3G    ./amd64/2004.1
2.4G    ./sparc/2004.1

If you go on the recently-heard "we're only releasing x86 and 686" for x86,
then the space there works out to ~2.2GB.

There are other projects (like hardened) that want to get their stuff on
the mirror as well, and I expect we're going to have at least one or two
new arches releasing this time around that missed the 2004.1 deadline.  As
such, I'm proposing a 2.5GB per arch/major-top-level project cap on file
size for the mirror.

Now, lest anyone get up in arms at this, I only care about the total size
of all the files used for a release.  So, when it comes time to put 2004.2
stuff up on the mirror, I'm going to look at the number of arches + major
top level projects (currently, only hardened) and multiple that by 2.5 to
get a total size cap.  As long as the total size is under that number,
that's fine with me.

Some notes:

* If an arch isn't releasing for 2004.2, then no space is allocated for
  them.
* If an arch is planning on releasing for 2004.2 and cancels at the last
  minute, then no space is allocated for them.
* I would greatly appreciate a heads up at least 2-3 weeks prior to a
  release about arches that *will* be releasing for 2004.2.  So far, I'm
  assuming x86, ppc, amd64 and sparc will all be releasing from an arch POV
  and I also assume hardened will release something as well.  So, that's a
  total of 12.5GB of data that I'm expecting.  If more arches will be
  releasing, please let me know as soon as possible so I can give a heads
  up to our mirrors.
* sub-projects, such as GameCDs, will need to fit into the existing space
  requirements.  Arches like AMD64 are unlikely to need a full 2.5GB of
  space, so this should allow some extra space for GameCDs and other
  special projects.  If there are other unique circumstances that may
  warrant special consideration, please feel free to discuss with me on
  IRC.

So, at this point, you have 12.5GB of available space to fill up with
whatever you want.  I don't care if it's 12.5GB devoted to one arch and
everyone else is left out in the cold -- that's up to you guys to figure
out.  I just need a firm number that I can communicate to our mirror
admins so they can plan accordingly. (again, if more arches are releasing,
please let me know ASAP)

--kurt

P.S. We will also have a torrent server available for distributing ISOs and
stages that might not make it into the above size cap.  At this point, we
have no alternate means of distributing this data (such as http or ftp) so
please plan what goes in the 12.5GB carefully.

--gDGSpKKIBgtShtf+
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2JziJPpRNiftIEYRAr0TAJoD0azc14ip4dHvPQxy/izKPo/fhQCghAdy
6kmV97xpBwEf5MbL/Ht4jLk=
=hCQ4
-----END PGP SIGNATURE-----

--gDGSpKKIBgtShtf+--