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 ;-) Dave
