Torrey McMahon wrote: > On 7/20/2009 2:11 PM, Garrett D'Amore wrote: >> John Forte wrote: >>> Garrett D'Amore wrote: >>>> In principle this looks good, and I'm almost ready to +1 it, but I >>>> have a few questions first: >>>> >>>> 1) I don't know enough about the FC protocol... will forcing target >>>> ports to reinitialize have any negative implications for the >>>> initiators? I'd like to understand the ramifications of any side >>>> effects. >>> The initiators will get a RSCN (Remote State Change Notification) >>> from the FC switch, which will generally cause them to rediscover >>> for any changes to the fabric, which is generally the desired >>> behavior from the administrator issuing this command. >> >> Does this have negative implications for any in-flight I/O? (I.e. is >> this command potentially destructive?) Are the implications >> restricted to just the target being reinitialized? (Sorry if it >> sounds like I'm being paranoid here, but to a certain extent a little >> paranoia can be helpful. :-) If its potentially destructive, then >> I'd like to have a warning issued to the administrator first. If it >> can't be destructive, then we needn't worry about it. > > Does the command reset the target port completely or just it's link to > the host that sends the command? When issuing it on the target port side, it causes a reset of the target port and when issuing it from the host port side, a reset of the host port is done. The same can pretty much also be accomplished by going to the switch and doing an offline/online of the desired switch port. > If you had a bad guy on a host and they continually reset a target > port completely you could cause issues on other hosts. Not like other > commands on other protocols couldn't do the same thing but you might > want to warn folks in the man page. Something like, "This command will > reset a storage target port impacting any host attached......" blah > blah blah. Yes, I think an explanation of the likely impact of this command is reasonable.
- John
