On 19/01/2011 13:26, Dermot McCluskey wrote: > Darren, > > On 01/19/11 12:42, Darren Kenny wrote: >> 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. >> > > So, does that imply that the Transfer checkpoint needs to be instantiated > and its estimate_size() method run before the disk selection phase of the > install? >
Hmm, yes it would, but also it would require you be able to access that checkpoint object, which of course you can't (that I know of). Ok, maybe that won't work then as we currently have things :( The alternative is then that the Application just has to figure what's reasonable as a minimum OS install size. While for media based installs, this information can be somewhat pre-determined because DC stores the sizes on the media. But for non-media based installs, what is reasonable as a minimum yet still be useful past the install and when things are up-and-running. Anyone got suggestions? Thanks, Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
