[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
I will prepare a new workspace and get back when it is ready for re-review. Thanks, Pavel Robert Thurlow wrote: > Pavel Filipensky wrote: > >> 5) default behavior:: limit action(s) to the current zone >> available options: -Z ...apply action(s) to all *non-global* zones >> >> >> So I propose to implement 5). Rob, Mike does it work for you? > > Yes, this works for me (with the later clarifications). > > Thanks Pavel, > Rob T
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Mike Gerdts wrote: > On Tue, Dec 2, 2008 at 3:44 AM, Pavel Filipensky > wrote: > >>> 5) default behavior:: limit action(s) to the current zone >>> available options: -Z ...apply action(s) to all *non-global* zones >>> >>> >>> So I propose to implement 5). >>> >> + add call of 'umountall -Z' to stop method /lib/svc/method/svc-zones >> > > The following: > > global# svcadm disable -t zones > > Should not cause NFS mounts in the global zone to go away. This > implies the need for: > 5) default behavior:: limit action(s) to the current zone available options: -Z ...apply action(s) to all *non-global* zones -Z will apply only to *non-global* zones, so it will not cause NFS mounts in the global zone to go away. > umountall -z zone ... > > svc-zones currently has the following shutdown logic: > > 1) zlogin $zone init 0 > 2) zoneadm -z $zone halt > 3) give up and print an error message > We can make it as: 1) zlogin $zone init 0 2) zoneadm -z $zone halt 2.5) umountall -Z 3) give up and print an error message or 1) zlogin $zone init 0 1.5) umountall -Z 2) zoneadm -z $zone halt 3) give up and print an error message This is an implementation detail which should be checked with zones people. So you basically agree with the soultion #5, or? --Pavel > It seems as though it may be useful to add 2.5 where it calls > "umountall -z $zone", possibly followed by one more "zoneadm -z $zone > halt" attempt. It does seem as though it is logic that belongs in > "zoneadm halt" rather than in service methods. > > Mike > >
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
On Tue, 02 Dec 2008 11:19:04 +0100, Pavel Filipensky wrote: > The fix "6675447 NFSv4 client hangs on shutdown if server is down > beforehand" > is not working for autofs/nfs mounts - must be reopened. 6778894 umountall -l still not really local yet --- frankB
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
On Tue, 02 Dec 2008 11:19:04 +0100, Pavel Filipensky wrote: > Interesting. The root cause is in /usr/sbin/umountall and how it > processes /etc/mnttab. > E.g. we have mounted NFS file system on mountpoint > /net/tb3.uk/tank/src/onnv-snapshots/onnv_66 > via autofs: > > /etc/mnttab will contain these 2 lines: > > tb3.uk:/tank/src/onnv-snapshots/onnv_66 > /net/tb3.uk/tank/src/onnv-snapshots/onnv_66nfs > -hosts/net/tb3.uk/tank/src/onnv-snapshots/onnv_66autofs > > /sbin/umountall -l will do this check: > > if [ -n "$LFLAG" -a "$fstype" = "nfs" ]; then > continue > fi > > obviously it will skip nfs, but will proceed with autofs - since both > use the same mountpoint, quite. > the call 'umount -a /net/tb3.uk/tank/src/onnv-snapshots/onnv_66' does > not know that it should > do the 'autofs' unmount (which should return EBUSY) and will do the 'nfs > 'unmount and will hang. though eventually I'd like to see forcible unmounts supported in autofs, ie. autofs should attempt to forcibly unmount its triggered mounts, ie. in the scope of NFS, do an NFS forcible umount. we could use that to deal with the general aspects of a dead server/down network in a later course of action. > The fix "6675447 NFSv4 client hangs on shutdown if server is down > beforehand" > is not working for autofs/nfs mounts - must be reopened. I'd rather like to see a new bug opened, will do so in a minute. --- frankB
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Frank Batschulat (Home) wrote:
> On Tue, 02 Dec 2008 10:24:59 +0100, Pavel Filipensky sun.com> wrote:
>
>
>> usefully attempt an all-zones umountall'. Fix for "6675447 NFSv4 client
>> hangs on shutdown if server is down beforehand"- has added the '-l' flag
>> (limit actions to the local file systems) to svc.startd:
>>system("/sbin/umountall -l" with this fix, we no longer unmount NFS there.
>>
>
> a bit of topic in the context of this proposal, but still...
> fwiw, I have to disagree here, despite the assumption above, I can
> prove you that 'umountall -l' still does attempt to unmount NFS file systems.
>
Interesting. The root cause is in /usr/sbin/umountall and how it
processes /etc/mnttab.
E.g. we have mounted NFS file system on mountpoint
/net/tb3.uk/tank/src/onnv-snapshots/onnv_66
via autofs:
/etc/mnttab will contain these 2 lines:
tb3.uk:/tank/src/onnv-snapshots/onnv_66
/net/tb3.uk/tank/src/onnv-snapshots/onnv_66nfs
-hosts/net/tb3.uk/tank/src/onnv-snapshots/onnv_66autofs
/sbin/umountall -l will do this check:
if [ -n "$LFLAG" -a "$fstype" = "nfs" ]; then
continue
fi
obviously it will skip nfs, but will proceed with autofs - since both
use the same mountpoint,
the call 'umount -a /net/tb3.uk/tank/src/onnv-snapshots/onnv_66' does
not know that it should
do the 'autofs' unmount (which should return EBUSY) and will do the 'nfs
'unmount and will hang.
The fix "6675447 NFSv4 client hangs on shutdown if server is down
beforehand"
is not working for autofs/nfs mounts - must be reopened.
--Pavel
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
On Tue, 02 Dec 2008 10:24:59 +0100, Pavel Filipensky wrote:
> usefully attempt an all-zones umountall'. Fix for "6675447 NFSv4 client
> hangs on shutdown if server is down beforehand"- has added the '-l' flag
> (limit actions to the local file systems) to svc.startd:
>system("/sbin/umountall -l" with this fix, we no longer unmount NFS there.
a bit of topic in the context of this proposal, but still...
fwiw, I have to disagree here, despite the assumption above, I can
prove you that 'umountall -l' still does attempt to unmount NFS file systems.
see: http://bugs.opensolaris.org/view_bug.do?bug_id=6544130
unfortunately my latest update from yesterday is not yet public.
what is happending is that 'umountall -l' indeed does trigger a 'umount -a'
for autofs triggered NFS mounts still in mnttab regardless above theory
statement.
re-doing my update to above bug here to show you the picture:
so I was finally able to gather a crash dump of this event. see comments section
for the path and attached threadlist.
the picture when the network was down and a shutdown initated after the network
has been taken down but before the idle autofs nfs mounts had been unmounted
looked like this:
> ::status
debugging crash dump vmcore.0 (64-bit) from opteron
operating system: 5.11 snv_102 (i86pc)
### autofs/nfs mounts:
ff01ade36eb8 autofs /net
ff01ade36de8 autofs /home
ff01ade36428 autofs /net/xenbld.sfbay/sp1
ff01ade36358 autofs /net/xenbld.sfbay/dskpool
ff01ade36288 autofs /net/xenbld.sfbay/export
ff01ade361b8 autofs /net/xenbld.sfbay/export/build
ff01ade360e8 autofs /net/xenbld.sfbay/export/xVM-Server
ff01ade36698 nfs /net/xenbld.sfbay/export/xVM-Server
ff01ade36018 autofs /net/xenbld.sfbay/export/xVM-Server/gates
ff01cd891ec0 autofs /net/xenbld.sfbay/export/xVM-Server/builds
ff01cd891df0 autofs /net/xenbld.sfbay/export/xVM-Server/gates-i14
ff01cd891d20 autofs /net/xenbld.sfbay/export/xVM-Server/builds-i14
ff01cd891c50 autofs /net/xenbld.sfbay/export/xVM-Server/builds-i13
ff01cd891b80 autofs /net/xenbld.sfbay/export/xVM-Server/gates-i12b7
ff01cd891ab0 autofs /net/xenbld.sfbay/export/xVM-Server/gates-i1...
ff01cd8919e0 autofs /net/xenbld.sfbay/export/xVM-Server/producti...
ff01cd891910 nfs /net/xenbld.sfbay/export/xVM-Server/builds
### same messages on the console about unkillable autofs services and
### nfs client mounts and:
NOTICE: [NFS4][Server: xenbld.sfbay][Mntpt:
/net/xenbld.sfbay/export/xVM-Server]NFS server xenbld.sfbay not responding;
still trying
### process tree still active:
> ::ptree
fbc29430 sched
ff01a99cba48 fsflush
ff01a99cc6a8 pageout
ff01a99cd308 init
ff01ae948320 automountd
ff01ae93c8e8 automountd
ff01a99b4538 powerd
ff01a99c9528 svc.configd
ff01a99ca188 svc.startd
ff01a99c4a50 sh
ff01a99c56b0 umountall
ff01a99b8318 umountall
ff01a99c0c70 umount
ff01ae9438e0 tail
### what's umountall doing ?
> ff01a99b8318::ps -tf
SPID PPID PGIDSIDUID FLAGS ADDR NAME
R 3224 3212 7 7 0 0x4200 ff01a99b8318 /sbin/sh
/sbin/umountall -l
T 0xff01aa1b4820
> 0xff01aa1b4820::findstack -v
stack pointer for thread ff01aa1b4820: ff0007ea9c70
[ ff0007ea9c70 _resume_from_idle+0xf1() ]
ff0007ea9ca0 swtch+0x160()
ff0007ea9d00 cv_wait_sig_swap_core+0x170(ff01a99b83d8,
fbcd65f8, 0)
ff0007ea9d20 cv_wait_sig_swap+0x18(ff01a99b83d8, fbcd65f8)
ff0007ea9dc0 waitid+0x2a0(0, c9a, ff0007ea9dd0, 83)
ff0007ea9ec0 waitsys32+0x30(0, c9a, 8047560, 83)
ff0007ea9f10 sys_syscall32+0x101()
### whats current active umount doing ?
> ff01a99c0c70::ps -tf
SPID PPID PGIDSIDUID FLAGS ADDR NAME
R 3226 3224 7 7 0 0x4a004000 ff01a99c0c70 umount -a
/net/xenbld.sfbay/export/xVM-Server/production-IPS-server /net/xenbld
T 0xff01aa1aabe0
> 0xff01aa1aabe0::findstack -v
stack pointer for thread ff01aa1aabe0: ff00076da0f0
[ ff00076da0f0 _resume_from_idle+0xf1() ]
ff00076da120 swtch+0x160()
ff00076da190 cv_timedwait_sig+0x1bd(ff00076da300, c0342750,
3b50b0)
ff00076da200 waitforack+0x99(ff00076da2d0, 10, ff00076da5e0, 0)
ff00076da290 connmgr_connect+0xfd(ff01ad5b3d80, ff01adc0f660,
ff01ae49eb68, 2, ff00076da2d0, ff01ad5b3da0, 1,
ff00076da5e0, 0)
ff00076da390 connmgr_wrapconnect+0x144(ff01ad5b3d80,
ff00076da5e0, ff01ae49eb68, 2, ff
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
> 5) default behavior:: limit action(s) to the current zone > available options: -Z ...apply action(s) to all *non-global* zones > > > So I propose to implement 5). + add call of 'umountall -Z' to stop method /lib/svc/method/svc-zones > Rob, Mike does it work for you? > > Since we are introducing a new option, we must go through PSARC case, > and I expect more opinions/discussions to appear/happen there. > > Thanks, > Pavel > > > ___ > nfs-discuss mailing list > nfs-discuss at opensolaris.org >
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Robert Thurlow wrote:
> 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.
There is no longer the 'window during shutdown where we could
usefully attempt an all-zones umountall'. Fix for "6675447 NFSv4 client
hangs on
shutdown if server is down beforehand"- has added the '-l' flag
(limit actions to the local file systems) to svc.startd:
system("/sbin/umountall -l"
with this fix, we no longer unmount NFS there.
Summary regarding where we try unmounting non-global zones nfs mounts
during system shutdown, in the time order:
1) stop method of system/zones called from the global zone:
---> /lib/svc/method/svc-zones
> zlogin -S $zone /sbin/init 0
-> own instance of svc.startd calls zone's stop method of
nfs/client
2) stop method of nfs/client called from the global zone:
currently does cross-zone unmounting via umountall -F nfs,
but this will be removed
3) svc.startd in the global zone, after it kills all the processes, it
calls:
(void) system("/sbin/umountall -l");
4) vfs_unmountall()
#1 ... can unmount non-global zone? YES. shutdown of zones can fail,
but will print the list of the zones which failed to shutdown
#2 ... can unmount non-global zone? NO(YES) we propose to avoid it in
this code review
#3 ... can unmount non-global zone? NO. removed in 6675447
#4 ... can unmount non-global zone? NO. never goes OTW
===
Let's take the decision.
REQUIREMENTS:
Rob:
a) the ability to do the 'all-zones unmount from global zone'
b) the 'all-zones unmount from global zone' should be part of the
regular system shutdown
Mike:
c) wants stop method nfs/client to work on the current zone
d) wants umountall(1M) to work on the current zone by default
The requirements have these priorities:
c) - highest
a)
b)
d) - lowest
It looks that most difficult to implement is b) - 'all-zones unmount
from global zone
should be part of the regular system shutdown'. We can add a code to
/lib/svc/method/svc-zones
which would at the very end of the stop method unmount all the
non-global zone mounts.
This would require a new semantics for the -Z option - see option #5
OPTIONS:
1) default behavior: don't limit action(s) to the current zone
available options: none
2) default behavior:: don't limit action(s) to the current zone
available options: -z ...limit action(s)to the current zone
3) default behavior:: limit action(s) to the current zone
available options: none
4) default behavior:: limit action(s) to the current zone
available options: -Z ...apply action(s) to all zones
5) default behavior:: limit action(s) to the current zone
available options: -Z ...apply action(s) to all *non-global* zones
So I propose to implement 5). Rob, Mike does it work for you?
Since we are introducing a new option, we must go through PSARC case,
and I expect more opinions/discussions to appear/happen there.
Thanks,
Pavel
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Pavel Filipensky wrote: > 5) default behavior:: limit action(s) to the current zone > available options: -Z ...apply action(s) to all *non-global* zones > > > So I propose to implement 5). Rob, Mike does it work for you? Yes, this works for me (with the later clarifications). Thanks Pavel, Rob T
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
On Tue, Dec 2, 2008 at 8:49 AM, Pavel Filipensky wrote: > Mike Gerdts wrote: >> >> On Tue, Dec 2, 2008 at 3:44 AM, Pavel Filipensky >> wrote: >> 5) default behavior:: limit action(s) to the current zone available options: -Z ...apply action(s) to all *non-global* zones So I propose to implement 5). >>> >>> + add call of 'umountall -Z' to stop method /lib/svc/method/svc-zones >>> >> >> The following: >> >> global# svcadm disable -t zones >> >> Should not cause NFS mounts in the global zone to go away. This >> implies the need for: >> > > > 5) default behavior:: limit action(s) to the current zone > available options: -Z ...apply action(s) to all *non-global* zones > Missed that... > -Z will apply only to *non-global* zones, so it will not cause NFS mounts > in the global zone to go away. >> >> umountall -z zone ... >> >> svc-zones currently has the following shutdown logic: >> >> 1) zlogin $zone init 0 >> 2) zoneadm -z $zone halt >> 3) give up and print an error message >> > > We can make it as: > > 1) zlogin $zone init 0 > 2) zoneadm -z $zone halt > 2.5) umountall -Z > 3) give up and print an error message > > or > > 1) zlogin $zone init 0 > 1.5) umountall -Z > 2) zoneadm -z $zone halt > 3) give up and print an error message > > This is an implementation detail which should be checked with zones people. > > So you basically agree with the soultion #5, or? That works for me. -- Mike Gerdts http://mgerdts.blogspot.com/
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
On Tue, Dec 2, 2008 at 3:44 AM, Pavel Filipensky wrote: > >> 5) default behavior:: limit action(s) to the current zone >> available options: -Z ...apply action(s) to all *non-global* zones >> >> >> So I propose to implement 5). > > + add call of 'umountall -Z' to stop method /lib/svc/method/svc-zones The following: global# svcadm disable -t zones Should not cause NFS mounts in the global zone to go away. This implies the need for: umountall -z zone ... svc-zones currently has the following shutdown logic: 1) zlogin $zone init 0 2) zoneadm -z $zone halt 3) give up and print an error message It seems as though it may be useful to add 2.5 where it calls "umountall -z $zone", possibly followed by one more "zoneadm -z $zone halt" attempt. It does seem as though it is logic that belongs in "zoneadm halt" rather than in service methods. Mike -- Mike Gerdts http://mgerdts.blogspot.com/
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
On Mon, Dec 1, 2008 at 3:20 PM, Robert Thurlow wrote: > Mike Gerdts wrote: > >> I can not think of a case where "umountall -Z ... " is an advisable >> command > > I don't know of a reason an admin would use it manually, > but I think it's important to be able to use this in the > system shutdown path, for reasons previously stated. > > Rob T The way that umountall is in the system shutdown path is what led this to being something worth fixing. Here's more of the story. Historically ypstop(1M) and ypstart(1M) have been acceptable mechanisms used to force a complete restart of NIS-related processes. To the best of my knowledge, there is no other documented mechanism prior to Solaris 10. Solaris 10 and later still document these and carry no scary warnings about side effects. As such, if a system administrator at a large organization were to decide to restart NIS processes across various releases of Solaris, "ypstop ; ypstart" would seem to be a reasonable thing to do. Else, complicated logic is involved to call svcadm on some releases and the traditional commands on others. Beginning with Solaris 10, ypstart and ypstop include: /usr/sbin/svcadm restart milestone/name-services Which seems safe enough... except: $ svcprop nfs/client | grep restart_on network/restart_on astring error nlockmgr/restart_on astring error cbd/restart_on astring error mapid/restart_on astring error rpcbind/restart_on astring restart keyserv/restart_on astring none gss/restart_on astring none name-services/restart_on astring refresh This causes nfs/client to restart when ypstop or ypstart is run. When nfs/client stops: $ svcprop nfs/client | grep stop/exec stop/exec astring /lib/svc/method/nfs-client\ %m $ grep umountall /lib/svc/method/nfs-client /sbin/umountall -F cachefs /sbin/umountall -F nfs When "/sbin/umountall -F nfs" runs in the global zone, it unmounts NFS file systems in all non-global zones. The global zone is fixed up when "/sbin/mountall -F nfs" is run immediately after. Unfortunately, "mountall -F nfs" does not similarly reach into non-global zones and as such all non-global zones remain broken. The same scenario exists for autofs. Now, getting back to the system shutdown doing the right thing with trying to clean up from bugs in the zone shutdown process Clearly the current implementation has serious implications for a properly behaving system that just had its NIS client reconfigured. If umountall needs to be run such that it takes action on all zones, it must not be triggered by a restart of name services. On the same token, disabling the nfs/client service in the global zone should not have an effect on the running state of non-global zones. -- Mike Gerdts http://mgerdts.blogspot.com/
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Mike Gerdts wrote: > The way that umountall is in the system shutdown path is what led this > to being something worth fixing. No, you're talking about SMF stop methods - that's different. I agree that we need to have a way for the stop methods to affect only mounts in their zones. But svc.startd will do a "umountall -l" not long before a halt; I'd like that to keep doing the all-zones unmount. > Now, getting back to the system shutdown doing the right thing with > trying to clean up from bugs in the zone shutdown process Clearly > the current implementation has serious implications for a properly > behaving system that just had its NIS client reconfigured. If > umountall needs to be run such that it takes action on all zones, it > must not be triggered by a restart of name services. On the same > token, disabling the nfs/client service in the global zone should not > have an effect on the running state of non-global zones. I'm with you on this, of course. Rob T
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Mike Gerdts wrote: > I can not think of a case where "umountall -Z ... " is an advisable > command I don't know of a reason an admin would use it manually, but I think it's important to be able to use this in the system shutdown path, for reasons previously stated. Rob T
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Pavel Filipensky wrote: > Regarding the default behavior and available options for umountall(1M) > there are these possibilities: > > 1) default behavior: don't limit action(s) to the current zone > available options: none > > 2) default behavior:: don't limit action(s) to the current zone > available options: -z ...limit action(s)to the current zone > > 3) default behavior:: limit action(s) to the current zone > available options: none > > 4) default behavior:: limit action(s) to the current zone > available options: -Z ...apply action(s) to all zones > > #1 .. existing situation > #2 .. mine original proposal > #3 .. Mike's proposal > #4 .. another possibility I favor #2, and would tolerate #4. #3 is not OK, IMHO. Rob T
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
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
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
On Fri, Nov 28, 2008 at 1:59 PM, Pavel Filipensky wrote: > Regarding the default behavior and available options for umountall(1M) there > are these possibilities: > > 1) default behavior: don't limit action(s) to the current zone > available options: none > > 2) default behavior:: don't limit action(s) to the current zone > available options: -z ...limit action(s)to the current zone > > 3) default behavior:: limit action(s) to the current zone > available options: none > > 4) default behavior:: limit action(s) to the current zone > available options: -Z ...apply action(s) to all zones > > #1 .. existing situation > #2 .. mine original proposal > #3 .. Mike's proposal > #4 .. another possibility > > > Originally, I was afraid of changing the default behavior of umountall(1M) > to avoid problems > to the existing applications. But it is hard to imagine that there is such > application which > uses umountall(1M) and relies that it will unmount filesystems also in > non-global zones. > As noted by Mike, during system shutdown, all zones should be down before > the autofs and > nfs client services stop in the global zones. > > Unless no one sees a problem with changing the default behavior, let's use > solution #3. > If someone sees a good reason to implement -Z option, let's use solution #4. I can not think of a case where "umountall -Z ... " is an advisable command, particularly if "mountall -Z ..." is not implemented. The reality is that systems tend to have things that depend on file systems and "umountall -Z" seems unlikely to do the right thing given the likely dependencies. An administrator that is sophisticated enough to manage all of those dependencies properly (which at best is likely "for zone in `zoneadm list`; do ... ; done") can insert the appropriate per-zone umountall or svcadm command. -- Mike Gerdts http://mgerdts.blogspot.com/
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Regarding the default behavior and available options for umountall(1M) there are these possibilities: 1) default behavior: don't limit action(s) to the current zone available options: none 2) default behavior:: don't limit action(s) to the current zone available options: -z ...limit action(s)to the current zone 3) default behavior:: limit action(s) to the current zone available options: none 4) default behavior:: limit action(s) to the current zone available options: -Z ...apply action(s) to all zones #1 .. existing situation #2 .. mine original proposal #3 .. Mike's proposal #4 .. another possibility Originally, I was afraid of changing the default behavior of umountall(1M) to avoid problems to the existing applications. But it is hard to imagine that there is such application which uses umountall(1M) and relies that it will unmount filesystems also in non-global zones. As noted by Mike, during system shutdown, all zones should be down before the autofs and nfs client services stop in the global zones. Unless no one sees a problem with changing the default behavior, let's use solution #3. If someone sees a good reason to implement -Z option, let's use solution #4. --Pavel > When would it be desirable for umountall to unmount file systems in > all zones? It seems to me that umountall will called during system > shutdown or just before a similarly crafted mountall. Unless mountall > is extended to do perform its work in all zones in the absence of the > -z option, I find the current behavior as dangerous in most usage > scenarios. > > 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 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. > > > >>4.2. Bug/RFE Number(s): >> 6502014 NFS mounts in non-global zones are unmounted if NFS >> is restarted in the global zone >> >>4.5. Interfaces: >> >> New option -z for umountall(1M). >> >>4.6. Doc Impact: >> >> This will be added to the umountall(1M) manpage: >> >> SYNOPSIS >> umountall [-k] [-s] [-F FSType] [-l | -r] [-z] [-n] >> >> >> umountall [-k] [-s] [-h host] [-z] [-n] >> >> ... >> >> -zLimit the action(s) only to the mounts >>coming from the current zone. >> > > I suggest instead that the -z option not be added and the following > man page change occurs: > > umountall causes all mounted file systems in the current > zone except root, /usr, /var, /var/adm, /var/run, /proc, and > /dev/fd to be unmounted. If the FSType is specified, > mountall and umountall limit their actions to the FSType > specified. There is no guarantee that umountall unmounts > busy file systems, even if the -k option is specified. > >
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
On Thu, Nov 27, 2008 at 6:01 AM, Pavel Filipensky wrote: > Hi, > > I need a code review for: > > 6777298 umountall(1M) -z ... limit unmounting action(s) to the current zone > 6502014 NFS mounts in non-global zones are unmounted if NFS is restarted > in the global zone > 6512906 Autofs mounts in non-global zones are unmounted when autofs is > restarted in the global zone > 6777323 smb mounts in non-global zones are unmounted when smb/client is > restarted in the global zone > > NOTE: 6777298 6777323 were created today and they have not been > propagated to bugs.opensolaris.org yet. > > The first CR in the list introduces a new option -z to umountall(1M). > The remaining CRs utilize the new > option int the stop methods for smf services - nfs/client, smb/client > and autofs. > > Since there is a change to a public interface of umountall(1M), I plan > to create a fast-track PSARC case. > Any experience how are PSARC done in OpenSolaris? Especially can anyone > recommend a sponsor? > > Thanks, > Pavel > > === > Below is the 'Technical Description' from my onepager draft: > > > 4. Technical Description: > >An additional command line option -z is proposed for umountall(1M). >This option, when used, will limit the unmounting action(s) only >to the current zone. >The use of -z option in non-global zones will have no effect since >non-global zones already do not attempt to unmount mounts coming >from different zones. (This was introduced as a part of the fix for >"5037418 umount: permission denied seen upon zone reboot".) >So the -z option will be effective when used in the global zone and >it will prevent umountall(1M) from unmounting mounts coming from >non-global zones. > >Primary consumers of the new -z option will be stop methods >of various smf services. Let's take the nfs service as an example. >Nfs mounts in non-global zones are unmounted if smf service >svc:/network/nfs/client:default is restarted in the global zone. >This is a bug as the nfs services in different zones should be >independent. The bug is logged as >"6502014 NFS mounts in non-global zones are unmounted if NFS is > restarted in the global zone" >This check shows that there are some more smf service that are not >zones independent: > >$ grep umountall /lib/svc/method/* > >/lib/svc/method/nfs-client: /sbin/umountall -F cachefs >/lib/svc/method/nfs-client: /sbin/umountall -F nfs >/lib/svc/method/smb-client: /sbin/umountall -F smbfs >/lib/svc/method/svc-autofs: /sbin/umountall -F autofs > >Effort was done to check that the use of the -z option is > consistent >with other commands. Many commands use -z together with zone ID: > > ipcrm [-z zone] > ipcs [-z zone] > pkill [-z zoneidlist] > pgrep [-z zoneidlist] > ps [-z zonelist] > prstat [-z zoneidlist] > >No command is currently using the plain -z option. However, older >version of ppriv(1) was using [-z]: > > ppriv -z [-v] > -z Lists all privileges available in the current > zone stdout. > > >There are no side effects of using -z option on other suboptions >to umountall(1). Using -z never changes the behaviour of other >suboptions, -z only only limits their scope. When would it be desirable for umountall to unmount file systems in all zones? It seems to me that umountall will called during system shutdown or just before a similarly crafted mountall. Unless mountall is extended to do perform its work in all zones in the absence of the -z option, I find the current behavior as dangerous in most usage scenarios. 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 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. > > >4.2. Bug/RFE Number(s): > 6502014 NFS mounts in non-global zones are unmounted if NFS > is restarted in the global zone > >4.5. Interfaces: > > New option -z for umountall(1M). > >4.6. Doc Impact: > > This will be added to the umountall(1M) manpage: > > SYNOPSIS > umountall [-k] [-s] [-F FSType] [-l | -r] [-z] [-n] > > > umountall [-k] [-s] [-h host] [-z] [-n] > > ... > > -zLimit the action(s) only to the m
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Webrev is here: http://cr.opensolaris.org/~pavelf/6777298/ My apologize, Pavel On 11/27/08 13:01, Pavel Filipensky wrote: > Hi, > > I need a code review for: > > 6777298 umountall(1M) -z ... limit unmounting action(s) to the current zone > 6502014 NFS mounts in non-global zones are unmounted if NFS is restarted > in the global zone > 6512906 Autofs mounts in non-global zones are unmounted when autofs is > restarted in the global zone > 6777323 smb mounts in non-global zones are unmounted when smb/client is > restarted in the global zone > > NOTE: 6777298 6777323 were created today and they have not been > propagated to bugs.opensolaris.org yet. > > The first CR in the list introduces a new option -z to umountall(1M). > The remaining CRs utilize the new > option int the stop methods for smf services - nfs/client, smb/client > and autofs. > > Since there is a change to a public interface of umountall(1M), I plan > to create a fast-track PSARC case. > Any experience how are PSARC done in OpenSolaris? Especially can anyone > recommend a sponsor? > > Thanks, > Pavel > > === > Below is the 'Technical Description' from my onepager draft: > > > 4. Technical Description: > > An additional command line option -z is proposed for umountall(1M). > This option, when used, will limit the unmounting action(s) only > to the current zone. > The use of -z option in non-global zones will have no effect since > non-global zones already do not attempt to unmount mounts coming > from different zones. (This was introduced as a part of the fix for > "5037418 umount: permission denied seen upon zone reboot".) > So the -z option will be effective when used in the global zone and > it will prevent umountall(1M) from unmounting mounts coming from > non-global zones. > > Primary consumers of the new -z option will be stop methods > of various smf services. Let's take the nfs service as an example. > Nfs mounts in non-global zones are unmounted if smf service > svc:/network/nfs/client:default is restarted in the global zone. > This is a bug as the nfs services in different zones should be > independent. The bug is logged as > "6502014 NFS mounts in non-global zones are unmounted if NFS is > restarted in the global zone" > This check shows that there are some more smf service that are not > zones independent: > > $ grep umountall /lib/svc/method/* > > /lib/svc/method/nfs-client: /sbin/umountall -F cachefs > /lib/svc/method/nfs-client: /sbin/umountall -F nfs > /lib/svc/method/smb-client: /sbin/umountall -F smbfs > /lib/svc/method/svc-autofs: /sbin/umountall -F autofs > > > Effort was done to check that the use of the -z option is > consistent > with other commands. Many commands use -z together with zone ID: > >ipcrm [-z zone] >ipcs [-z zone] >pkill [-z zoneidlist] >pgrep [-z zoneidlist] >ps [-z zonelist] >prstat [-z zoneidlist] > > No command is currently using the plain -z option. However, older > version of ppriv(1) was using [-z]: > >ppriv -z [-v] > -z Lists all privileges available in the current > zone stdout. > > > There are no side effects of using -z option on other suboptions > to umountall(1). Using -z never changes the behaviour of other > suboptions, -z only only limits their scope. > > > 4.2. Bug/RFE Number(s): > 6502014 NFS mounts in non-global zones are unmounted if NFS > is restarted in the global zone > > 4.5. Interfaces: > > New option -z for umountall(1M). > > 4.6. Doc Impact: > > This will be added to the umountall(1M) manpage: > > SYNOPSIS > umountall [-k] [-s] [-F FSType] [-l | -r] [-z] [-n] > > > umountall [-k] [-s] [-h host] [-z] [-n] > > ... > > -zLimit the action(s) only to the mounts > coming from the current zone. > > > ___ > nfs-discuss mailing list > nfs-discuss at opensolaris.org >
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Pavel, I'll review this on Monday when I'm back in the office. Tom Sent from my iPhone On Nov 27, 2008, at 2:56 PM, Pavel Filipensky wrote: > Webrev is here: > > http://cr.opensolaris.org/~pavelf/6777298/ > > My apologize, > Pavel > > On 11/27/08 13:01, Pavel Filipensky wrote: >> Hi, >> >> I need a code review for: >> >> 6777298 umountall(1M) -z ... limit unmounting action(s) to the >> current zone >> 6502014 NFS mounts in non-global zones are unmounted if NFS is >> restarted >> in the global zone >> 6512906 Autofs mounts in non-global zones are unmounted when autofs >> is >> restarted in the global zone >> 6777323 smb mounts in non-global zones are unmounted when smb/ >> client is >> restarted in the global zone >> >> NOTE: 6777298 6777323 were created today and they have not been >> propagated to bugs.opensolaris.org yet. >> >> The first CR in the list introduces a new option -z to umountall(1M). >> The remaining CRs utilize the new >> option int the stop methods for smf services - nfs/client, smb/client >> and autofs. >> >> Since there is a change to a public interface of umountall(1M), I >> plan >> to create a fast-track PSARC case. >> Any experience how are PSARC done in OpenSolaris? Especially can >> anyone >> recommend a sponsor? >> >> Thanks, >> Pavel >> >> === >> Below is the 'Technical Description' from my onepager draft: >> >> >> 4. Technical Description: >> >>An additional command line option -z is proposed for >> umountall(1M). >>This option, when used, will limit the unmounting action(s) >> only >>to the current zone. >>The use of -z option in non-global zones will have no effect >> since >>non-global zones already do not attempt to unmount mounts >> coming >>from different zones. (This was introduced as a part of the >> fix for >>"5037418 umount: permission denied seen upon zone reboot".) >>So the -z option will be effective when used in the global >> zone and >>it will prevent umountall(1M) from unmounting mounts coming >> from >>non-global zones. >> >>Primary consumers of the new -z option will be stop methods >>of various smf services. Let's take the nfs service as an >> example. >>Nfs mounts in non-global zones are unmounted if smf service >>svc:/network/nfs/client:default is restarted in the global >> zone. >>This is a bug as the nfs services in different zones should be >>independent. The bug is logged as >>"6502014 NFS mounts in non-global zones are unmounted if NFS >> is >> restarted in the global zone" >>This check shows that there are some more smf service that >> are not >>zones independent: >> >>$ grep umountall /lib/svc/method/* >> >>/lib/svc/method/nfs-client: /sbin/umountall -F cachefs >>/lib/svc/method/nfs-client: /sbin/umountall -F nfs >>/lib/svc/method/smb-client: /sbin/umountall -F smbfs >>/lib/svc/method/svc-autofs: /sbin/umountall -F autofs >> >> >>Effort was done to check that the use of the -z option is >> consistent >>with other commands. Many commands use -z together with >> zone ID: >> >> ipcrm [-z zone] >> ipcs [-z zone] >> pkill [-z zoneidlist] >> pgrep [-z zoneidlist] >> ps [-z zonelist] >> prstat [-z zoneidlist] >> >>No command is currently using the plain -z option. However, >> older >>version of ppriv(1) was using [-z]: >> >> ppriv -z [-v] >> -z Lists all privileges available in the current >> zone stdout. >> >> >>There are no side effects of using -z option on other >> suboptions >>to umountall(1). Using -z never changes the behaviour of other >>suboptions, -z only only limits their scope. >> >> >>4.2. Bug/RFE Number(s): >> 6502014 NFS mounts in non-global zones are unmounted if NFS >> is restarted in the global zone >> >>4.5. Interfaces: >> >> New option -z for umountall(1M). >> >>4.6. Doc Impact: >> >> This will be added to the umountall(1M) manpage: >> >> SYNOPSIS >> umountall [-k] [-s] [-F FSType] [-l | -r] [-z] [-n] >> >> >> umountall [-k] [-s] [-h host] [-z] [-n] >> >> ... >> >> -zLimit the action(s) only to the mounts >>coming from the current zone. >> >> >> ___ >> nfs-discuss mailing list >> nfs-discuss at opensolaris.org >> > > ___ > nfs-discuss mailing list > nfs-discuss at opensolaris.org
[nfs-discuss] Code review for 6777298 and friends (6502014 6512906 6777323)
Hi, I need a code review for: 6777298 umountall(1M) -z ... limit unmounting action(s) to the current zone 6502014 NFS mounts in non-global zones are unmounted if NFS is restarted in the global zone 6512906 Autofs mounts in non-global zones are unmounted when autofs is restarted in the global zone 6777323 smb mounts in non-global zones are unmounted when smb/client is restarted in the global zone NOTE: 6777298 6777323 were created today and they have not been propagated to bugs.opensolaris.org yet. The first CR in the list introduces a new option -z to umountall(1M). The remaining CRs utilize the new option int the stop methods for smf services - nfs/client, smb/client and autofs. Since there is a change to a public interface of umountall(1M), I plan to create a fast-track PSARC case. Any experience how are PSARC done in OpenSolaris? Especially can anyone recommend a sponsor? Thanks, Pavel === Below is the 'Technical Description' from my onepager draft: 4. Technical Description: An additional command line option -z is proposed for umountall(1M). This option, when used, will limit the unmounting action(s) only to the current zone. The use of -z option in non-global zones will have no effect since non-global zones already do not attempt to unmount mounts coming from different zones. (This was introduced as a part of the fix for "5037418 umount: permission denied seen upon zone reboot".) So the -z option will be effective when used in the global zone and it will prevent umountall(1M) from unmounting mounts coming from non-global zones. Primary consumers of the new -z option will be stop methods of various smf services. Let's take the nfs service as an example. Nfs mounts in non-global zones are unmounted if smf service svc:/network/nfs/client:default is restarted in the global zone. This is a bug as the nfs services in different zones should be independent. The bug is logged as "6502014 NFS mounts in non-global zones are unmounted if NFS is restarted in the global zone" This check shows that there are some more smf service that are not zones independent: $ grep umountall /lib/svc/method/* /lib/svc/method/nfs-client: /sbin/umountall -F cachefs /lib/svc/method/nfs-client: /sbin/umountall -F nfs /lib/svc/method/smb-client: /sbin/umountall -F smbfs /lib/svc/method/svc-autofs: /sbin/umountall -F autofs Effort was done to check that the use of the -z option is consistent with other commands. Many commands use -z together with zone ID: ipcrm [-z zone] ipcs [-z zone] pkill [-z zoneidlist] pgrep [-z zoneidlist] ps [-z zonelist] prstat [-z zoneidlist] No command is currently using the plain -z option. However, older version of ppriv(1) was using [-z]: ppriv -z [-v] -z Lists all privileges available in the current zone stdout. There are no side effects of using -z option on other suboptions to umountall(1). Using -z never changes the behaviour of other suboptions, -z only only limits their scope. 4.2. Bug/RFE Number(s): 6502014 NFS mounts in non-global zones are unmounted if NFS is restarted in the global zone 4.5. Interfaces: New option -z for umountall(1M). 4.6. Doc Impact: This will be added to the umountall(1M) manpage: SYNOPSIS umountall [-k] [-s] [-F FSType] [-l | -r] [-z] [-n] umountall [-k] [-s] [-h host] [-z] [-n] ... -zLimit the action(s) only to the mounts coming from the current zone.
