On 01/18/11 11:32 AM, Alok Aggarwal wrote:
On Mon, 17 Jan 2011, Darren Kenny wrote:
On 14/01/2011 23:00, Alok Aggarwal wrote:
- Partitions should not be too small for a given architecture
Can you clarify what "too small" means?
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?
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....
- Keith
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
