Hi Dave,
On 03/24/09 20:27, Dave Miner wrote:
> John Levon wrote:
>> On Tue, Mar 24, 2009 at 02:27:31PM +0100, jan damborsky wrote:
>>
>>> * search for first disk with at least 'recommended' space available
>>> (taking into account further upgrades and swap and dump devices).
>>>
>>> * If such disk is not found, pick up the first one with at least
>>> minimum space available (size of bits to be installed plus some
>>> reserve - 20% for now is used)
>>>
>>> * if there is no disk with at least minimum required space available,
>>> inform user and give up.
>>>
>>> Please let me know, if it might sound reasonable.
>>
>> I presume there's a step 0:
>>
>> * use disk specified in the manifest, if any, reporting an error and
>> quitting if it's not the minimum size
>>
>> This sounds like a good plan.
>>
>
> 20% seems like a lot of padding, it'll typically add somewhere around
> 500 MB to the required size; how accurate are our estimates of
> installed size here, anyway?
At the time being, AI takes hard coded value 4GB for size of bits
to be installed and uses the same algorithm as LiveCD for calculating
minimum disk size:
min_disk_size = <size_of_bits>*1.2 ~ 4.8GB
Looking at the system installed by AI (build 109, babel_install),
zfs reports ~4.24GB for BE root dataset:
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 5.25G 17.6G 73K /rpool
rpool/ROOT 4.24G 17.6G 19K legacy
rpool/ROOT/opensolaris 4.24G 17.6G 3.84G /
rpool/dump 511M 17.6G 511M -
rpool/export 604K 17.6G 21K /export
rpool/export/home 582K 17.6G 21K /export/home
rpool/export/home/jack 562K 17.6G 562K /export/home/jack
rpool/swap 512M 18.1G 16K -
This is more comparing to the system installed using LiveCD - the
culprit (or one of culprits) seems to be /var/pkg/download directory:
# du -sh /var/pkg/download/
1.0G /var/pkg/download/
Based on this, I think that we should probably clean that cache
after installation is done. But we still need to take that space
into account for the installation. Or do you happen to know
if it might be possible to install without populating download cache ?
Algorithm for calculating size of bits to be installed from IPS repository
given the package list is currently work in progress (tracked by bug 4546).
I have recently started to dig into this problem and done some
observations - it seems there are interesting problems to be solved.
I think that the main issue might be that generic IPS API which might
be used for obtaining statistics is not available - e.g. querying for
information about how much space will particular IPS object (package,
metacluster, ...) require to be successfully installed on the target.
As far as I am aware of, for now there is only size information reported
for the package as result of 'pkg info' command - it looks like:
# pkg -R /tmp/a info SUNWcsd
Name: SUNWcsd
Summary: Core Solaris Devices
Category: System/Core
State: Installed
Authority: opensolaris.org
Version: 0.5.11
Build Release: 5.11
Branch: 0.110
Packaging Date: Fri Mar 20 17:38:53 2009
Size: 44.29 kB
FMRI: pkg:/SUNWcsd at 0.5.11,5.11-0.110:20090320T173853Z
The report is the same on both Sparc as well as x86 - man page
doesn't say what this number means, I assume it is just
total size of package.
If one wants to know, what would be the size of objects to be
really installed on particular architecture, it seems that content
of the package has to be inspected. e.g if I want to know total
size of all files in SUNWcsd package:
x86:
# pkg -R /tmp/a contents -r -t file -o pkg.size SUNWcsd | awk 'BEGIN
{pkg_sum = 0} {pkg_sum+=$1} END {print pkg_sum}'
24469
sparc:
# pkg -R /tmp/a contents -r -t file -o pkg.size SUNWcsd | awk 'BEGIN
{pkg_sum = 0} {pkg_sum+=$1} END {print pkg_sum}'
28995
It becomes more interesting when we start to play with
let's say babel_install, since first we need to obtain
complete list of packages particular metacluster installs.
Looking at the 109 system installed with babel_install,
it has more than 600 packages:
# pkg list | wc -l
611
I have taken a closer look at how long might take
to obtain this information for one package. I have tried
for package localy installed:
# time pkg contents -t file -o pkg.size SUNWcsd | awk 'BEGIN {pkg_sum =
0} {pkg_sum+=$1} END {print pkg_sum}'
24469
real 0m3.707s
user 0m2.038s
sys 0m0.206s
And when bigger one has been tried:
# time pkg contents -t file -o pkg.size SUNWcs | awk 'BEGIN {pkg_sum =
0} {pkg_sum+=$1} END {print pkg_sum}'
25309681
real 0m3.820s
user 0m2.192s
sys 0m0.195s
So it seems that size of package doesn't matter too much,
the operation took ~3-4 seconds for one package which
would mean >1/2 hour for 600 packages if we do this on per
package basis.
Thinking about this, I am wondering if we might cooperate
with IPS team on introducing some kind of API which might
be used for those type of queries - all calculation would
be then done on server side. Something like
'calculate and give me total size of files which would be
installed by babel_install'
Please let me know if going this way (do this calculations
on server side and introduce new IPS API for those queries)
might be reasonable or if other approach might be more
appropriate or reasonable.
Thank you,
Jan
