On Tue, 2009-06-30 at 16:31 -0500, Nicolas Williams wrote:
> On Tue, Jun 30, 2009 at 02:12:57PM -0700, Roman V Shaposhnik wrote:
> > On Tue, 2009-06-30 at 13:46 -0700, Glenn Faden wrote:
> > > >>> My personal question now is : why didn't I find it by myself ! :-)
> > > >>>
> > > >> Because it doesn't work. See:
> > > >>
> > > >> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/autofs/auto_vnops.c#auto_trigger_mount
> > > >>
> > > >> 1403 /*
> > > >> 1404 * Cross-zone mount triggering is disallowed.
> > > >> 1405 */
> > > >> 1406 if (fnip->fi_zoneid != getzoneid())
> > > >> 1407 return (EPERM); /* Not owner of mount */
> > > >
> > > > This place is easy to fix if you ask me. The real question is what kind
> > > > of long lasting impact would allowing such a thing have. And this is
> > > > a conversation I'm very interested in having.
> Removing this code is not the right thing to do.
Just to be clear: nobody is proposing to remove it unconditionally.
> also prevents one from sharing an autofs mount to more than one zone,
> which cannot work out well since it would allow a filesystem mounted by
> one zone to be visible by another.
I guess I'm not quite following here. Could you, please, ellaborate?
IOW, what is an example of a global zone autofs mount point that:
* can be triggered from zoneA
* make the resulting filesystem appear in zoneB
assuming that zoneA and zoneB have distinct zone roots?
> > To repeat *my* question: would it be possible to have a tunable
> > parameter that would force all the FS traffic into a global
> > zone the way this workaround does for NFS:
> > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_subr.c#4985
> That's a very big hammer that doesn't have quite the effect that you
> might think that it does. Or at least for me figuring out its effect
> requires reading much code and it currently looks very, very iffy as it
> causes EIO to be returned in some cases, for example, as in nfs4_open():
> 614 if (nfs_zone() != VTOMI4(*vpp)->mi_zone)
> 615 return (EIO);
> Probably not what you want!
No. That actually gives me exactly what I want (to the extent that I
global-zone# mount server:/share /containers/local-zone/root/mnt
local-zone# cat /mnt/test.txt
If it were not for the scary comment that this is a temporary hack
that needs to go away -- I'd be using it for real work already.
> > Since all the processes running in zones are nothing but regular
> > processes I would like to have an option of making their FS
> > related requests behaving like ones. Per my explicit request,
> > of course.
> Then don't use zones :/
But...but...but...they are so nice (when they work ;-)). Seriously
thought, for the project I'm part of -- I can't use anything but
> The problem at hand is a reentrance issue in the VM.
Could you, please, point me to the most authoritative CR that captures
zones-discuss mailing list