On Tue, 18 Jan 2011, Keith Mitchell wrote:

Restating:
    - Partitions should be greater than a minimum size

That is, enforce the minimum size that 'zpool create' expects
(few hundred MB i think?).

Is this not the OS minimum size, not the minimum size for a zpool?

I was proposing the latter check but you bring up a good
point that perhaps it should be the former.

I think there would need to be ways to enforce the former for the root pool, and the latter for any other arbitrary zpool, no?

Yes, we'd need both these checks. If the 'is_root' attribute
is true, then the check will be for minimum OS size. If it's false, it will be for minimum size for a zpool.

If it is the OS minimum size, where does that information come from?

I know with a CD, the estimated size is stored in a 'dot-file' but how would one determine this minimum size for an AI type install where it's all dependent on
the packages to be installed.

I believe that the size is hardcoded at present in AI (unless
that has changed in the last few months).

It's been an RFE for a while that we dynamically calculate this. I'm not sure, but I think AI->CUD should allow for precisely determine the minimum required space, as we'll have access to the pkg API which is capable of figuring out the total size for a clean install. (It could be that the pkg API can't do that yet; I'm not sure if that functionality was implemented yet)


It would seem to be something that the 'Transfer' module could provide, but I
think it would be quite time-consuming to actually determine a real value.

What would be an acceptable 'estimate'?

An orthogonal question here is - if Target is to be responsible
for ensuring that a disk/slice is atleast the minimum OS size,
then there needs to be an API to communicate the minimum OS size
to Target.

The app/MVC would determine the minimum OS size (by looking at
the dot file or by calling transfer) and subsequently call an API
to let Target know that value.

I think it depends on the transfer method. For cpio based, since the transferred contents are statically determined during the DC build process, filing that info away in a dot-file and passing it to transfer seems more efficient. For pkg-based, assuming the aforementioned feature of the pkg API is available, I think transfer would need to be responsible for such a calculation - though it may be that we have a 'chicken and egg' problem if the pkg API requires a pkg image area to work on to perform the calculations....

I agree. At the same time though, I believe the app/MVC
should be the place to do size determination (based upon
the transfer mechanism being used). Target does not have
the necessary context to tell what sort of transfer method
is being used.

Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

Reply via email to