1:34 p.m.
At the moment, the Fedora updates tree is somewhat out of
hand (look, wow - 27G).
Does anyone have any specific and concrete objections to
removing older, superceded, updates?
Bill
2:34 p.m.
On Thu, Sep 09, 2004 at 02:34:18PM -0400, Bill Nottingham wrote:
At the moment, the Fedora updates tree is somewhat out of
hand (look, wow - 27G).
Does anyone have any specific and concrete objections to
removing older, superceded, updates?
It was useful for me to be able to go back and fetch all the older
kernel updates to see which one broke qemu.
So I would say that it would be useful to have older updates available.
They don't have to be in the same directory, of course.
--L
9:32 p.m.
On Thu, Sep 09, 2004 at 09:34:21PM +0200, Lennert Buytenhek wrote:
It was useful for me to be able to go back and fetch all the older
kernel updates to see which one broke qemu.
So I would say that it would be useful to have older updates available.
They don't have to be in the same directory, of course.
ISTR this comes up on mirror-list-d occasionally, and the preferred
solution seems to be what you are suggesting.
An obsolete-updates directory could be easily --exclude'd, and people
who need to back out an update for whatever reason would still have
the old updates available.
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
10:59 p.m.
On Thu, Sep 09, 2004 at 09:32:49PM -0500, Steven Pritchard wrote:
On Thu, Sep 09, 2004 at 09:34:21PM +0200, Lennert Buytenhek wrote:
> It was useful for me to be able to go back and fetch all the older
> kernel updates to see which one broke qemu.
>
> So I would say that it would be useful to have older updates available.
> They don't have to be in the same directory, of course.
ISTR this comes up on mirror-list-d occasionally, and the preferred
solution seems to be what you are suggesting.
An obsolete-updates directory could be easily --exclude'd, and people
who need to back out an update for whatever reason would still have
the old updates available.
From a mirroring perspective, it is much more efficient to have an
all-updates directory containing all the real files, and a
latest-updates directory containing only symlinks to the newest files
in the other directory. That way rsync can sync the symlinks with
--delete and you don't have to download the files again when they
become obsolete and would otherwise be moved between directories.
11:53 a.m.
On Thu, Sep 09, 2004 at 11:59:21PM -0400, Charles R. Anderson wrote:
>From a mirroring perspective, it is much more efficient to have
an
all-updates directory containing all the real files, and a
latest-updates directory containing only symlinks to the newest files
in the other directory. That way rsync can sync the symlinks with
--delete and you don't have to download the files again when they
become obsolete and would otherwise be moved between directories.
But then there wouldn't be anything to --exclude easily (for mirrors
concerned about space).
To avoid the multiple-download problem, when the new update appears, a
hard link to the old update could be created in the obsolete-updates
directory. The updates directory copy could then be deleted a week
later (or whatever). As long as mirrors are using rsync -H and
mirroring regularly, they'd never need to re-download an update.
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
12:33 a.m.
On Fri, Sep 10, 2004 at 11:53:15AM -0500, Steven Pritchard wrote:
On Thu, Sep 09, 2004 at 11:59:21PM -0400, Charles R. Anderson wrote:
> >From a mirroring perspective, it is much more efficient to have an
> all-updates directory containing all the real files, and a
> latest-updates directory containing only symlinks to the newest files
> in the other directory. That way rsync can sync the symlinks with
> --delete and you don't have to download the files again when they
> become obsolete and would otherwise be moved between directories.
But then there wouldn't be anything to --exclude easily (for mirrors
concerned about space).
Sure there would. Just download the latest-updates directory,
following the symlink targets.
To avoid the multiple-download problem, when the new update appears,
a
hard link to the old update could be created in the obsolete-updates
directory. The updates directory copy could then be deleted a week
later (or whatever). As long as mirrors are using rsync -H and
mirroring regularly, they'd never need to re-download an update.
Not everyone uses rsync... Symlinks could be supported by ftp
mirroring.
7:15 a.m.
On Thu, Sep 09, 2004 at 02:34:18PM -0400, Bill Nottingham wrote:
At the moment, the Fedora updates tree is somewhat out of
hand (look, wow - 27G).
Does anyone have any specific and concrete objections to
removing older, superceded, updates?
Superceded updates should be preserved somehow, but outside of the
current updates tree. How to best achieve this for mirroring
efficiency I leave up to the guys to comment on who have actual
experience with rsync et al. :-)
Best regards,
Daniel
7162
days inactive
7168
days old
6 comments
5 participants
participants (5)
-
Bill Nottingham -
Chuck Anderson -
Daniel Roesen -
Lennert Buytenhek -
Steven Pritchard