On 03/17/10 06:56 AM, William Schumann wrote: > On 03/12/10 05:11 PM, Dave Miner wrote: >> On 03/12/10 08:26 AM, William Schumann wrote: >>> http://cr.opensolaris.org/~wmsch/bug-8575/ >>> http://defect.opensolaris.org/bz/show_bug.cgi?id=8575 >>> >> >> Based on the fact that, right now, we do not have actual computation >> of the installed size based on the set of packages in the AI manifest, >> why is fixing this bug the right thing to do right now? Doesn't the >> current state of things at least allow a smaller package set than 4 GB >> to be installed into a sufficient space, which it appears won't be >> possible with this fix? > Correct, this would prohibit cases as in *13793* > <http://defect.opensolaris.org/bz/show_bug.cgi?id=13793> - B130: AI is > not to able install reduced profiles on 4GB (3800MB) media > http://defect.opensolaris.org/bz/show_bug.cgi?id=13793 > > So the size can differ drastically depending on what packages are > selected in the manifest, so terminating the installation based on > current estimates should be avoided. > > This fix could be modified to issue warnings only, and the wording > changed so that the sizes refer to a "common size for a normal Solaris > installation", for example. The installation would not be terminated - > the interested user would scan the log for errors ("_E") shortly after > launching the installation. Or perhaps a console message could appear > via stderr. >
This might provide a better experience than the current behavior. > What this fix does offer today is a hook into checking the size of the > install slice, which is the container for the root pool, and the > behavior is table-driven (easily changed). At the end of the day, the > absolute and recommended minimum sizes are just numbers that can be > returned by om_get_min_size() and om_get_recommended_size() > transparently to the caller, once we are able to get (more) precise > sizes from IPS, whenever that might happen. > > As for when that might happen, see *Bug 385* > <http://defect.opensolaris.org/bz/show_bug.cgi?id=385> - fast access to > size of packages in repo > Currently, this is marked as a P3 enhancement with no milestone, last > commented in October, filed January 2008. If anyone has a more > representative bug number, please let me know. > Actually, I don't think we're strongly dependent on that. The transfer module is being reimplemented in terms of the pkg API, and that offers the granularity to create a plan without executing, result of which should be usable to determine size of the required image. > (FYI, presently, the default disk selection algorithm will look for a > disk of over the recommended minimum size, which is over 12GB. If disk > selection criteria is specified (e.g., target_disk_name), the disk will > be accepted regardless of its size, and installation will proceed.) > Right, that's what I thought was the case. Dave > William >> >>> At the core, calls om_get_min_size() to compare to the slice size. This >>> is the absolute minimum, as opposed to the recommended minimum. >>> If less than the absolute, abort installation. >>> If less than the recommended, log errors and proceed. >>> >>> Sample log message for > minimum, but < recommended: >>>> <OM_I Mar 12 22:22:33> Checking minimum size for install slice >>>> <OM_E Mar 12 22:22:33> Install slice 0: >>>> <OM_E Mar 12 22:22:33> 9.98 GiB ( 20939390 sectors) is less than the >>>> recommended size >>>> <OM_E Mar 12 22:22:33> 4.80 GiB ( 10065920 sectors) is the absolute >>>> minimum size. >>>> <OM_E Mar 12 22:22:33> 12.35 GiB ( 25899008 sectors) is the >>>> recommended minimum size. >>> >>> Tested slices that were too big and too small. Tested differing slice >>> numbers. Tested creating non-root slice that did not leave enough room >>> for the root slice. Tested no partitions and no slices in manifest or on >>> disk. Tested creating a partition in the manifest and not specifying a >>> slice. >>> Regression tested GUI >>> >>> Also fixed a inconsequential bug found by lint where there should have >>> been parentheses to make an assignment take precedence over a logical. >>> >>> do 'make lint' >>> William >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
