We have flipped and flopped on this issue
over the years, with the most recent discussion captured in bug 307804
I don't think anything has changed since
then (and the opinion then seemed to tip slightly to "leave both").
I don't think this disk space is related
to build machine shortage, since we don't leave many copies on build machine,
and as far as I know, there is no problem with space on "downloads"
(except, for the usual reasons and care .. we still don't want it to get
out of control, since then we could overwhelm our mirror servers space).
If, after reading those histories, you
still think we could switch again, I suggest you open a new bug with the
request for the decision to be revisited, again.
Also, about these reports, while I've
not made a chart-over-time, it seems the disk usage is improving. Scanning
through the latest reports, there's nothing that jumps out, at me as obviously
needing big improvement. Keep up the good work, everyone.
(Though, if others know otherwise, please
open bugs against projects that need to do some more aggressive cleanup).
issues (cross-project-issues-dev@xxxxxxxxxxx)" <cross-project-issues-dev@xxxxxxxxxxx>
03/02/2011 04:42 AM
Disk space, repos and unpacked jars
I notice that many, if not all of the archived
repos that we provide contain BOTH the original *.jar artifacts as well
as the packed *.jar.pack.gz artifacts.
This seems like a big waste of disk space
and download bandwidth to me.
There was some case for the unpacked *.jar
artifacts in the past, when Java 1.4 and below was still widespread and
thus the unpack utility was not universally available. But given that more
and more projects now require Java 1.5, keeping the unpacked *.jar artifacts
in the archives seems unnecessary and wasteful. A similar argument holds
for the actual online accessible repos.
To give you a rough idea of how much could
be saved, I looked at a local copy of the Helios SR2 repo (not claiming
that removing all unpacked Jar’s from Helios is a viable option yet):
helios> du -k 201102250900
helios> find . -name '*.jar.pack.gz'
-print | sed -e 's,\.pack\.gz,,g' | xargs rm
helios> du -k 201102250900
As you see, disk usage goes down from 1
Gig to 500 Meg. Multiply this by all our mirrors plus the bandwidth taken
for downloads… and consider that the argument applies for Project’s individual
repos, multiple versions of downloadable archived repos, … and see how
this could be related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=335809
Thoughts, comments anyone ?
Any good reason for not cleaning the upacked
Martin Oberhuber, SMTS
/ Product Architect – Development Tools, Wind
River direct +43.662.457915.85 fax
cross-project-issues-dev mailing list