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.  Yes, this code
prevents having a single automounter in the g-z for all zones, but it
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.

See the other alternative already discussed in this thread, where the
mount(2) syscall would detect the loopback NFS mount and convert it to a
lofs mount while pretending to the zone that it's still an NFS mount.

> 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!

> 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 :/

The problem at hand is a reentrance issue in the VM.  Let's fix that.
If that's ETOOHARD then let's consider alternatives, but let's not bend
the system into a pretzel.  Converting loopback NFS mounts into lofs
mounts seems reasonably promising in that the changes needed for it seem
well isolated, though it may have its own pitfalls (for example,
pretending that a lofs mount is an NFS mount probably has consequences
for statvfs() and pathconf(), but not pretending that it is an NFS mount
means doing something about how to represent the original NFS location
as a mount special).
zones-discuss mailing list

Reply via email to