Absolutely. +1 to Mike. http://blogs.sun.com/mrbill/entry/separation_is_a_good_thing
And from the SVM world: http://blogs.sun.com/mrbill/entry/in_the_zone_with_jet bill. 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: > > 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/* > _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
