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 ?
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.
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.
> > This way we wouldn't have to explicitely specify the
> > root fs via NIC. And we could be running the system
> > on multipath.
> >
we need to specify i/fs for rootfs 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 ?
> > Cheers,
> >
> > Hannes
>
> I agree. Also, there could be more than one critical disk.
> So, maybe both approaches make sense. One that adds a flag
> saying the disk is critical and one that lets fcoemon exit
> without tearing down fcoe instances.
I agree and I suggested same above with more details of marking flag for
critical disk's in fcoe i/f cfg files.
Vasu
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
