Mike Gerdts wrote: > When would it be desirable for umountall to unmount file systems in > all zones?
If we're bringing the system-as-a-whole down, we try to stop zones, but if one of them fails to shut down, it is better to try to unmount the filesystems mounted in them to free resources on the servers. This is nice behaviour on a network; without it, other clients will be unable to get locks and state until lease periods expire. > During system shutdown, all zones should be down before the autofs and > nfs client services stop in the global zones. In the event that some > zone is not shut down, this means that it is likely stuck in a > shutting down state and any calls to unmount "stuck" nfs mounts in > that zone will result in a hung system call and an SMF stop method > timeout. It's easy, especially during development, to get zones that won't shut down - all you need is one vnode refcount wrong, for example. We're not ever going to be able to guarantee that such a refcount leak won't escape into the wild (and several have done so). I have also seen global zone threads able to do the unmount logic successfully on behalf of a zone - because that work is not affected by refcounts. In summary, I like Pavel's idea and code changes here. I would not object to the inverse flag to get back the "unmount everything" semantics. I'm not really willing to lose those semantics. > It seems to me that there is a real chance[1] that the RPC calls would > not even be routable to an NFS server. See, for example, > http://bugs.opensolaris.org/view_bug.do?bug_id=6476438. I believe there is a window during shutdown where we could usefully attempt an all-zones umountall. I'd want to have that be after zone shutdown, but I think that's already the case. Rob T
