ISO sizes problem (searching for a solution)
Hi!
As everybody that has created debian cds using debian-cd knows, it is
difficult to estimate the image sizes, till now I had been using my own
estimations at gluck and it is now when I switched to debian-cd current
estimations that DVD and CD sizes have gone wrong.
So, I'd like to fix what we currently have in debian-cd, Raphael sugested
(if I recall well) that we should change the disks-$ARCH directory size by
the size of the installer-$ARCH directory (Raphael, correct me if this was
not what you told me), the problem here is that not all the images in the
installer dir are used, for ecample:
du -s debian/dists/sarge/main/installer-i386/current/images/
60064 debian/dists/sarge/main/installer-i386/current/images
ls debian/dists/sarge/main/installer-i386/current/images/
MANIFEST MD5SUMS cdrom floppy hd-media netboot
The thing is that only 20 megs aprox of this dir are used, which corresponds
to the cdrom and floppy dirs, but this can change with the arches.
The only way I see to estimate images sizes in the cds would be to do the
download/cp of the images from the web/mirror into the tmp directory before
we calculate the sizes, thus in the build.sh script.
I can see, without thinking too much on the problem and not knowing the code
well, at least a way to do this:
calling the boot scripts with a "predownload" parameter that only does the
downloading or cp of all the stuff to a dir into the tmp space, and then
when the boot script is called in the usual way by the Makefile, they check
that this dir is already created and they don't download the stuff again.
This would mean that we need to modify all boot scripts.
What we'd get of this, would be the real size of all the extra stuff put on
the cds for all the arches in real time, wich is one of the parameters we
are looking for.
If we take a real example where the space reserved for boot files was 0...
CD 1 filled with 652854624 bytes ... (limit was 660602880)
this means that it is calculating around 622 megs of packages, and it ended
up with an image of 650MB
If we analyse the space in the tmp dir for CD1...
/CD1$ du -s --apparent-size *
11 README.html
76 README.mirrors.html
38 README.mirrors.txt
6 README.txt
1 debian
1430 dists
771 doc
20457 install
115 md5sum.txt
19 pics
640410 pool
986 tools
we can see that pool has 626 megs, which is a little bit more than
calculated (anybody knows where this 4 megs came from?), and then we see
that most of the other space is from the install directory (the space I was
trying to estimate coming from the boot images and all that) and then a bit
from the doc, tools and dists (packages files), if we stimate by hand the
size of these last ones and we calculate the size of the images we can have
a good stimation on the size of the files we are putting in, don't you
think? For example, here the estimation would say that for doc, packages and
other stuff we need 4 megs, then we calculate the size of install, which is
20, and we add that to the 622 that we had already, and we get 646, which is
a little bit under the ISO size, but that is a good estimation as we didn't
take into account the extras that the filesystem imposes.
That is another of the problems we have, estimating the extra space added by
the filesystem, for what I know, that can change quite a lot the size of the
images on some arches, I know we already have some ways to try to estimate
this, but I haven't yet examined this, anybody that knows other arches or
the scripts we use for this wants to say something on this? is this really
problematic? or to we already have a solution for this?
We'll I now have a quite fast raid 0 here at home, so I'll be making some
tests, here, but what I don't have is a good bandwith to be able to make
tests with all arches and right now I only have a mirror for i386 :-(
I accept all kind of help, comments, hints, ... with all this, I don't know
the code we use for all this size estimations, so anybody wanting to help is
at least as qualified as I aam ;-)
Regards...
--
Manty/BestiaTester -> http://manty.net
Reply to: