[EMAIL PROTECTED] wrote On 08/02/06 05:59,:

And new semantics to allow that would have one twist: you really only want to allow this zone-requested loopback when the filesystem to mount is share(1M)'d to the zone. You can't allow zones to have arbitrary loopback mounts created upon request. So this might need support for share -F lofs and corresponding support to (auto)mount global zone lofs exports in local zones.

The global zone knows all this and could deal with this gracefully
using some form of protocol that establishes not only what the zone wants
to mount but also where.

Which goes back to my original question: solution is best to address this and related problems? The original case in the CR was fast failover in netra-HA. Now zones is impacted by this as well. I see three options right now:

1. Fix the deadlock condition
2. Extend the protocol to allow a mount request to be resolved by other means 
(lofs in this case)
3. Introduce user space NFS server, which could serve instead of or as an extension (in cases like this) to the kernel server (oh boy)
[4. See if ZFS does not have this issue and ignore the above :) ]

2. and 3. seem less desirable unless 1. is just two complex.

More interesting is it when a local zone shares something and another
zone wants to mount it ....

Now this raises 3. to interesting and more broadly useful. While at it, lets make it do CIFS as well, or extend Samba to do NFS. [1]

Of course, the alternative is to just sell more NAS!


[1] helping out on a concept where users are provisioned their own zone and it would be great to share data to PCs. The user can control what is shared to others, a la Network Neighborhood.


zones-discuss mailing list
zones-discuss mailing list

Reply via email to