On Wed, 2010-03-31 at 08:42 +0200, Hannes Reinecke wrote:
> Vasu Dev wrote:
> > On Tue, 2010-03-30 at 09:04 -0700, Joe Eykholt wrote:
> >> Hannes Reinecke wrote:
> >>> Vasu Dev wrote:
> >>>> This is protect destroying fcoe interface while used
> >>>> as root filesystem.
> >>>>
> >>>> Adds -r option to accept root interface name then sets up
> >>>> rootfs flag for its associated fcoe_ports, that flag
> >>>> is later used to ignore any subsequent FCOE_DESTROY
> >>>> operation on root interface.
> >>>>
> >>> Hmm. So you never ever expect the rootfs to be multipathed?
> >>>
> >>> Not sure this is a clever design.
> >>>
> >
> > Yeah clearly not by not considering multipathing.
> >
> >>> I'd rather have it implemented via signal handlers;
> >>> eg SIGTERM would should down fcoemon without shutting
> >>> down running connections, and eg SIGUSR1 or SIGHUP
> >>> would be shutting down all connections.
> >>>
> >
> > If I understood correct then you are suggesting SIGTERM will be used in
> > "/etc/init.d/fcoe stop" to only kill/shutdown fcoemon while leaving all
> > fcoe interfaces active, created from "/etc/init.d/fcoe start", am I
> > right ? In that case what would be use of destroying all interfaces in
> > SIGHUP including one or two used for rootfs ?
> >
> That would be for 'forced shutdown', ie stop FCoE now.
> Not something you'd use in the shutdown scripts, but a
> functionality admins might want to have.
>
I see.
> > Instead I'd prefer "/etc/init.d/fcoe stop" to destroy all fcoe
> > interfaces created by its counterpart "/etc/init.d/fcoe start" with the
> > exception of never allowing or doing critical interface/s destroy for
> > critical disks (e.g. rootfs), this would include accidentally preventing
> > critical interfaces destroy from "fcoeadm -d" application.
> >
> Don't think that'll work.
> Determining the 'critical' interfaces is a really awkward task.
> And easy to get wrong.
>
> I've been down that road trying to design iSCSI shutdown scripts.
> It doesn't work.
>
> Main reason here is the 'normal' shutdown sequence:
>
> - kill all daemons
> - shutdown network interfaces
> - umount all filesystems
> - halt system
>
> Point here is that it's trying to umount _ALL_ filesystems,
> regardless if they are mount from fstab, by a user, or whatever.
> And umount can _only_ proceed if the device serving the fs
> is accessible at this point.
> So we might get away with marking all NIC and rootfs devices,
> but if the user mounted a fs on an FCoE device by hand
> and shuts down the system we're still stuck.
>
>
Yeah that is problem for aldl fcoe active NICs, so either all active
FCoE NICs needs to be marke to not get stopped during fcoe & network
service stop, alternately fcoe service script needs to unmount all
non-rootfs manual fcoe mounts but not sure how to keep track of them, so
I'm fine with earlier though some may argu that fcoe service stop will
never destroy fcoe interfaces created by its fcoe service start is not
clean fcoe service stop but again that is not me since I' fine with that
given these fcoe un-mounting issues.
> > Currently "/etc/init.d/fcoe start" creates fcoe for only configured
> > ethernet interfaces and each i/f configuration is expected
> > at /etc/fcoe/cfg-<if name> to create fcoe on them, so how about adding
> > an additional config param there as: FCOE_DESTROY="yes" or "no" ? If its
> > value is no then fcoemon would never destroy that i/f and all critical
> > i/f can be configured as FCOE_DESTROY="no". What do you think on this ?
> >
> > Destroying all fcoemon i/f configured as FCOE_DESTROY="yes" can be moved
> > to SIGHUP or SIGUSR1 and then have fcoe service stop send
> > SIGHUP/SIGUSR1 to kill fcoemon, that would also prevent i/fs destroying
> > if fcoemon exited due to unexpected error in its main select loop.
> >
> Why do you insist on tearing down all connections on terminating fcoemon?
> Apart from a design POV?
>
Well, I had these feedback to address:-
1. Do clean fcoe shutdown
2. Prevent accidental fcoe i/f destory on critical i/fs such as root,
so block i/f destory on them from fcoeadm -d.
3. Also prevent NIC shutdown on critical i/fs.
I was only trying my best to address above, I still don't know how to
fix 3 if someone goes and shoot on the foot by calling "ifconfig down"
on root i/f or network service stop w/o shutdown case.
So I was trying my best to address 1 and 2, but from starting this patch
work I had concern of only never destroying root if, then why not do
same for all, but was only trying to be clean as much possible for 1 & 2
feedback above, since I wasn't sure on any above therefor I asked again
in last response "unless not destroying all fcoe interfaces on
"/etc/init.d/fcoe stop" is okay with all, you seems to be okay with that
but lets see what others think on this ?"
If someone still want #2 then I think config approach is a option and
destros could still mark all fcoe config as FCOE_DESTROY="no" while
creating fcoe i/f cfg files but that would be effectively same as never
destroying all fcoe interface on fcoe service stop, so again I'm fine
with just don't destroy any fcoe i/f on fcoe service stop.
> I personally find it a quite dangerous behavior, as daemons are prone
> to tripping over and being killed unexpectedly. And if the standard
> action then is terminate all connections things will get really awkward.
> Think of OOM situations; the _last_ thing we want is to have fcoemon
> terminating all connection just because it's got a SIGTERM from the
> OOM killer.
>
Agreed as I said in last response "can be moved
to SIGHUP or SIGUSR1 ... that would also prevent i/fs destroying if
fcoemon exited due to unexpected error in its main select loop".
I'll get patch out for that with only SIGHUP doing fcoe i/f destroy.
> And I'm pretty sure the target doesn't care if we cleanly shutdown
> a connection or not, so we're not losing much in leaving the
> connections open during shutdown.
>
Agreed, also fabric would logout initiator on missed FIP keep alive/link
down.
Vasu
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
