On 18/01/2011 22:00, Dave Miner wrote: > 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.
That works for me - so this would be an attribute of a Zpool object that an application could modify if needed. > > >>>>> 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. > I believe that it would be useful if a Transfer checkpoint could have a 'TransferXXX.estimate_size()' method - it would not just be useful for an application, but may also useful for Transfer itself when determining progress, maybe. And it would also allow for the Transfer, whether it is IPS, CPIO, or whatever, to do what is necessary to figure it out appropriately. Thanks, Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
