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
tested it):
   global-zone# mount server:/share /containers/local-zone/root/mnt
    local-zone# cat /mnt/test.txt
    Hello world!

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
zones.

> The problem at hand is a reentrance issue in the VM.

Could you, please, point me to the most authoritative CR that captures
this issue?

Thanks,
Roman.

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to