Sorry for not responding earlier. I think that a simple walkthrough rescan on existing channel/id/lun will be OK in 99% of the cases. When the target was reconfigured (when one adds luns for example), a simple rescan will not pick up the changes (or worse). Seams that there is reason why there is no kernel based rescan function on a target today - only rescan scripts that walk through everything and call the device rescan code. Anyway, I see that this conversation may have been picked up by another thread discussing uevents and unit attention. http://www.spinics.net/lists/linux-scsi/msg50241.html -----Original Message----- From: Mike Christie [mailto:michaelc@xxxxxxxxxxx] Sent: 10 March, 2011 22:29 To: Hamburger, Menny Cc: linux-scsi@xxxxxxxxxxxxxxx; James.Bottomley@xxxxxxx Subject: Re: [PATCH] sd: sd should not modify read capacity, cache type or write protect flag on rescan when there is a transport error On 03/10/2011 02:49 AM, Menny_Hamburger@xxxxxxxx wrote: > 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 I think we should always rescan. The values could have changed on the target even if we have not actually sent a command and had it failed, so either way we need to pick up new values. > 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. Kernel. In the iscsi and fc class we already do a scan for devices when the transport comes back up from the kernel, so this rescan of devices values can just run from the same function. ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±þÇ‹ø¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf
