Mike Christie wrote: [...] > for a orderly removal of some object, like someone shutting down > a iscsi session, we are going to hit that path, but the command will not > get sent. However, for unorderly removal, like ripping out a usb device > or FC rport or iSCSI session being removed due to dev_loss_tmp expiring > then we do not want the command sent. So it seems like it may be > intended behavior. Certainly depends on how the SCSI mid-low API is used. I only know how sbp2 does it. It calls scsi_remove_device on soft shutdown as well as on hot unplug. (Earlier it only called scsi_remove_host which calls scsi_remove_device.) The last time I checked (2.6.16), this *always* called SCSI high-level's shutdown methods, particularly sd_sync_cache. sbp2 sends that command in the soft shutdown case but completes it with DID_NO_CONNECT in the hot unplug case, like any other commands. I don't know which states an "sdev" and "shost" is exactly put through, and luckily I never needed to know so far. Sbp2 does not use scsi_device_set_state. It also does not deal with "starget" or any transport sidekick. -- Stefan Richter -=====-=-==- -=== -==-- http://arcgraph.de/sr/ - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
