On 03/25/09 19:43, Dave Miner wrote: > jan damborsky wrote: >> 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 ? >> > > I don't believe there's a way to not populate the download cache, but > it will be cleaned up after the package installation if the image has > the flush-content-cache-on-success property set to True. So we do > need to include some overhead in the calculation to account for it, > and perhaps 20% isn't too far off ;-)
And we will likely need to double it once AI will be enhanced to determine exact size of bits to be installed :-) Jan
