Mike, I think there are still two open issues still here: 1) Should we always rescan when transport comes back up? My own opinion to this question is that doing a full rescan may be an overkill In this case. If the decision is not to rescan always (only when we have invalid capacity, cache type, write protect flag), we will need to maintain Additional state information in the device to indicate that the current values are invalid and a rescan is required. James stated that it is a layering violation to test the host byte of the result in order to decide whether or not a rescan is required, so we will need setup this state information in any case of failure when getting these properties from the device. 2) Should we rescan from within the kernel, or issue a uevent (hotplug) that would be picked up by userland (that would initiate the rescan)? Rescanning from within the kernel seems a bit more "clean", however there may be other considerations here. -----Original Message----- From: Mike Christie [mailto:michaelc@xxxxxxxxxxx] Sent: 10 March, 2011 02:01 To: James Bottomley Cc: Hamburger, Menny; linux-scsi@xxxxxxxxxxxxxxx Subject: Re: [PATCH] sd: sd should not modify read capacity, cache type or write protect flag on rescan when there is a transport error Yeah. Menny, I think you can just do the scsi/iscsi_rescan_target option I suggested in my pseudo patch where when the transport comes back online the iscsi class calls some helper scsi function that calls scsi_rescan_device for each device on the target, so proper values are picked up. ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±þÇ‹ø¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf
