Mike Christie wrote:
James.Smart@xxxxxxxxxx wrote:
michaelc@xxxxxxxxxxx wrote:
Oh yeah, I ccd linux-scsi for this patch and not others,
because JamesS
and them are not on fcoe devel list, and it seems like all fc drivers
fail the sync cache command.
What happens is that we remove the rport which sets the rport state,
then the fc class removes the target. This causes the target and its
devices to be removed, which can cause a sync cache to be sent. But
because the the rport is not in the online state it will fail
the command.
Well, excepting detachment paths, if we're tearing the rport down, it's
because
we've already lost connectivity to the target, so there's no way a sync
cache would ever succeed. It's a suprise-removal scenario.
Yeah, I am only talking about the paths where we want a clean shutdown
like if for fcoe we did echo ethX > /sys/module/fcoe/destroy. For normal
fc do we want to be able to remove rpots too? Did you guys do that with
the ioctl modules before? Then there is the module removal case. I think
for module removal we want a clean shutdown too, but I am not sure if
other people feel that for module removal there are gaurantees like that.
So during a clean shutdown are drivers supposed to remove the targets by
calling scsi_remove_target to remove the devices, then remove the rports
through the class?
Or for the case where we are stopping a host (rmmod or single host stop
like with fcoe), should drivers call
1. fc_remove_host()
This could be modified to cleanup shutdown targets then remove rports.
We could then have a rport shutdown callback which the class could call
and drivers could cleanup and shutdown the rport here before it is freed.
2. scsi_remove_host()
3. cleanup internal host resources.
4. scsi_put_host().
--
To unsubscribe from this list: 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
