Shawn,
On 03/17/10 07:10 PM, Shawn Walker wrote:
On 03/17/10 12:13 PM, Dave Miner wrote:
On 03/17/10 06:56 AM, William Schumann wrote:
...
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.
Yes and no. Right now, the API doesn't provide an estimated size for
the operation, that's RFE 7736.
However, you can use the pkg.client.api ImageInterface to get the size
of all the packages that are in the plan. That will give you the
installed size of the packages, but it won't include the amount of
space needed to store the compressed downloads, the package manifests,
etc.
I might also add that, currently, performing a planning operation
requires the retrieval of the package manifests for all of the
packages that might be installed as part of the operation if they
aren't already cached in the image.
Having tested the pkg.client.api solution (discussed recently on
pkg-discuss), I would say that this solution is too time-consuming to be
practical in this situation. Before AI can begin disk selection, it
must run this estimate, which takes on the order of 10 minutes and must
download almost 200MiB of manifests somewhere - keep in mind that the
target has not necessarily been selected, formatted, etc. The size
computation must precede disk selection, which is followed by the disk
layout phase, so that if there is an error in the disk layout or Target
Instantiation, etc., the user will no longer be aware of it within a few
seconds of the start of auto-install, which is currently the case.
Also, since the package manifests are not necessarily downloaded to the
target in this case, they must either be copied to the selected target
or just deleted. In recent tests, the download to do the plan for the
default AI manifest is 191MiB (in var/pkg/: pkg/, publisher/, and tmp/)
Examining other solutions to getting the size estimate before proceeding
with this fix.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
