Nicolas Williams wrote:
On Thu, Jul 22, 2010 at 06:04:31PM +0100, Andrew Gabriel wrote:
Robert Gordon wrote:
On Jul 22, 2010, at 10:57 AM, Andrew Gabriel wrote:
Sorry, but why is this restriction necessary?
The team thought that if an administrator created a zone to
partition data with the intent to share data from that zone,
allowing another zone to share it's root, probably didn't make
sense.
Are you saying that this is something we should not actively prohibit ?
Let the administrator decide. All you achieve by adding arbitrary
restrictions is you will prevent someone from using Zones to solve
an issue they have, for which Zones would otherwise have been ideal,
and everyone loses. There are plenty of other reasons to use Zones
which are nothing to do with partitioning data.
At least one restriction is needed: only one of the g-z and ngz can
share any of the ngz's resources.
But because existing systems can only share ngz resources from the g-z
you'll necessarily have to deal with what to do when an ngz tries to
share a resource already shared by the g-z. The question is: how?
I can see any number of options, such as:
1) Don't allow ngzs to share filesystems unless they've been marked as
capable of it, which in turn will only happen if the relevant
datasets have been marked as not shareable by the g-z, which in turn
can only happen if they aren't shared by the g-z. Thereafter you
could not share that ngz's filesystems from the g-z.
2) Don't allow ngzs to share filesystems shared by the g-z. What error
will be returned to the ngz sysadmin though?
3) Don't allow the g-z to share filesystems shareable by ngzs.
4) Don't allow booting of ngzs whose datasets are shared by the g-z, and
don't allow the g-z to share datasets owned by a booted zone.
(1) is fully backwards compatible, but probably requires lots of extra
work.
(2) and (4) are only slightly backwards incompatible, and that
incompatibility strikes me as tolerable. (4) probably requires
significant extra work too.
(3) Would be a very noticeable, incompatible change.
There may be other options too.
If I understood correctly that there's some technical reason a
directory can't be shared by more than one NFS instance, then check
for just that. Don't add other unnecessary restrictions,
particularly ones which break current functionality which people may
be using.
Right, that's (2) above, and it's the simplest option.
It's less restrictive than 2). Allow both g-z and ngz to share
directories, but only one at a time (first come, first served) on a per
share basis. i.e. you can share it unless another NFS instance already is.
As far as I know, the system call to share a filesystem isn't a public
interface, so it's not of great consequence what the error returned is,
as long as share(1M) can make some sense of it.
I just tried sharing an NFS mounted filesystem (which isn't allowed on
Solaris), and amusingly, I get the following misleading error message:
# df -k /mnt
Filesystem kbytes used avail capacity Mounted on
a20:/export/home 248415166 22862738 225552427 10% /mnt
# share -F nfs /mnt
NFS: Cannot share filesystems in non-global zones: /mnt
Could not share: /mnt: operation not supported
#
The syscall actually returned Err#66 EREMOTE, which is reasonable.
The mapping to a textual error is completely bogus though.
--
Andrew Gabriel
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
