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 firstname.lastname@example.org