public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Kurt Lieber <klieber@gentoo.org>
To: gentoo-dev@gentoo.org
Subject: [gentoo-dev] The release of 1.4 and its impact on our mirrors
Date: Wed, 23 Jul 2003 15:48:26 -0400	[thread overview]
Message-ID: <20030723194823.GJ9959@mail.lieber.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

Folks --

One issue that came out of today's manager meeting was the amount of space
that GRP and some of the new livecds will require for 1.4_release.  As I
understand it, that number hovers right around 10GB at the moment.

We have already received numerous complaints from our mirror admins about
the amount of disk space we chew up now.  For reference, here is a break
down:

9.7G    ./releases
139M    ./snapshots
17G     ./distfiles
6.6G    ./experimental

We can clean out some space in the /releases directory by deleting some of
the old 1.4_rc* stuff, but we will still have a significant overall size
increase as a part of 1.4_final.  We will be working on reducing the size
of /distfiles as well, but this will be nothing more than a temporary,
tactical fix.  We still need a longer term strategic fix.

I'd like to come up with a solution that allows each arch the flexibility
it requires to create new livecds, GRP packages, etc.  But I'd also like to
be mindful and respectful of our mirrors.  

I'd like to hear suggestions from you all on the best way to achieve this.
Some ideas that I've heard so far include:

* creating separate directories that are optional for our mirrors to 
  support.  GRP would be a prime candidate for this given the space it
  requires.  Mirrors short on disk space could choose not to mirror these
  files.
* assigning each arch a quota for the files it may use outside of
  /distfiles.  This quota would apply to liveCDs, things in /experimental
  as well as everything within /releases (as well as /grp if we make that a
  separate top level directory)  To be effective, this quota would need to
  be around the ~3GB level given the number of arches we support.

Those are simply two ideas that have been proposed so far.  I'm sure you
guys will have more.  The only requirements at this point are:

* We cannot expect our system of mirrors to give us an unlimited amount of
  disk space. (they've already started to complain)
* We cannot afford to lose many mirrors.  Especially in North America,
  source mirrors are in short supply.
* We must expect /distfiles to continue growing as we continue to add new
  ebuilds. So solutions involving "reducing the size of /distfiles" will
  not be feasible except as a short-term, stop-gap measure.

Thoughts?  Ideas?

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

             reply	other threads:[~2003-07-23 19:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-23 19:48 Kurt Lieber [this message]
2003-07-23  8:40 ` [gentoo-dev] The release of 1.4 and its impact on our mirrors Alvaro Figueroa Cabezas
2003-07-23 21:01   ` Kurt Lieber
2003-07-23  9:28     ` Alvaro Figueroa Cabezas
2003-07-23  9:30       ` Alvaro Figueroa Cabezas
2003-07-24  0:11       ` [gentoo-dev] " Pieter Van den Abeele
2003-07-24  0:55         ` Nathaniel McCallum
2003-07-24  2:07           ` [gentoo-dev] Python on the liveCD Nathaniel McCallum
2003-07-24  9:29             ` Seemant Kulleen
2003-07-23 20:36 ` [gentoo-dev] The release of 1.4 and its impact on our mirrors Matthew Walker
2003-07-23 20:39 ` Tal Peer
2003-07-23 21:10   ` Jon Portnoy
2003-07-23 21:41   ` Alec Berryman
2003-07-24  7:35 ` [gentoo-dev] (crazy?) proposal to reduce load and disk on mirrors Håvard Wall
2003-07-23  5:50   ` Fred Van Andel
     [not found]     ` <3F1F9174.6010504@ifi.uio.no>
2003-07-23  6:04       ` Fred Van Andel
2003-07-24  5:54   ` Raimundo Bilbao
2003-07-23  6:42     ` Fred Van Andel
2003-07-24  7:30       ` Robin H.Johnson
2003-07-23  7:53         ` Fred Van Andel
2003-07-24  6:35     ` bdharring
2003-07-23  7:22       ` Fred Van Andel
2003-07-24  9:32   ` Mix Sella
2003-07-24 16:39   ` gerrynjr
2003-07-24 15:59     ` Tom Payne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030723194823.GJ9959@mail.lieber.org \
    --to=klieber@gentoo.org \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox