Mike Gerdts wrote:
> On Tue, Aug 26, 2008 at 5:07 PM, Ethan Quach <[EMAIL PROTECTED]> wrote:
>
>> Hey Jerry,
>>
>> I just thought about something regarding the zones dataset
>> namespace. Instead of creating the dataset for zone roots at:
>>
>> rpool/export/zones/z1/rpool/ZBE1
>>
>> Maybe we should insert the "roped off" ROOT container dataset
>> like we do in the global zone:
>>
>> rpool/export/zones/z1/rpool/ROOT/ZBE1
>>
>> so that we confine the place where we know boot environment roots
>> live. The reason we do this is in the global zone is so that we
>> don't have to troll through potentially thousands of datasets
>> (sorting out whatever's been created in the shared area) to find
>> BE roots. This same problem would occur in the zone BE namespace.
>>
>> Thoughts?
>>
>
> rpool/ROOT seems to be redundant and it repeats itself. :)
>
> In the global zone, rpool/ROOT makes sense because there needs rpool
> and ROOT perform different duties. In a non-global zone,
> rpool/export/zones/z1 is equivalent to the global zone's rpool. To
> maximize synergies (and end abuse of /export - see filesystem(5)), I
> suggest:
>
Sure, that's fine. That part isn't really relevant from what I was trying
to convey though.
> This is the equivalent of the global zone's rpool. Or in an
> environment where there is a pool per zone, it may be z1pool.
>
> rpool/zones/z1
>
> This is managed by zoneadm and beadm. If all goes well, they both use
> libzonecfg to minimize the chance of divergence.
>
> rpool/zones/z1/ROOT
> rpool/zones/z1/ROOT/be1
> rpool/zones/z1/ROOT/be2
>
> The rest are available for use within the zone and may be mounted other places
>
> rpool/zones/z1/*
>
rpool/zones/z1 is the zonepath, and I don't know if we're planning
on delegating that dataset to the zone (for zone reasons I suppose).
Based on Jerry's proposal, the zonepath is not delegated. Hence the
need for:
rpool/zones/z1/<pool>/ROOT/ZBE1
The <pool> level is delegated, and that was what I was thinking the
zone can use as its "free-range" area.
thanks,
-ethan
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
