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:
>> Maybe we should insert the "roped off" ROOT container dataset
>> like we do in the global zone:
>> 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.
> 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
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.
> This is managed by zoneadm and beadm. If all goes well, they both use
> libzonecfg to minimize the chance of divergence.
> The rest are available for use within the zone and may be mounted other places
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
The <pool> level is delegated, and that was what I was thinking the
zone can use as its "free-range" area.
zones-discuss mailing list