On 01/18/11 04:21 PM, Alok Aggarwal wrote:
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.
I believe the simple thing here is to allow for a minimum size to be
associated with a pool, and it defaulted to the ZFS minimum. If the
application has a hint as the minimum size, then it can provide that info.
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.
Target shouldn't care, it's an app issue. At the same time, a dummy
image could be created in tmpfs just to get the catalogs and generate
the size data, to eliminate the chicken-egg issue Keith notes.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
