On Mon, 2013-01-28 at 16:48 +0100, Hannes Reinecke wrote: > On 01/28/2013 04:44 PM, Bart Van Assche wrote: > > On 01/28/13 16:05, Jeremy Linton wrote: > >> What I think your looking for is RSCN (Registered State Change > >> notification). > >> Hook that, and then check the name server. This will tell you when > >> ports get > >> added/removed. You can then report luns against lun 0 of all the > >> known target > >> ports. This allows you to transparently detect changes. > >> > >> Otherwise, you run the risk of trapping UA's in the lower level > >> portions of > >> the stack that _REALLY_ need to be propagated to the controlling > >> driver or > >> application. > > > > Thanks for the feedback. Unfortunately sending an RSCN is only > > possible when using Fibre Channel as transport layer. I'm looking > > for a solution that also works with other SCSI transports, e.g. > > iSCSI and SRP. > > > And we're already doing that. Rather, the FC HBAs do exactly this. > > So the proposal would be to export a 'virtual' LUN0 if none is > present, so that we always have a device to talk to, right? > > Shouldn't be too hard; we already create a 'virtual' LUN0 during > scanning, only we delete it if no LUNs are found. > So we're already doing this, only we don't tell :-)
I'm not sure I'd like to leave virtual LUN-0 around if we find nothing because it's going to cause confusion and be nasty in cases where a physical lun 0 is created later. However, don't the standards define this ignored lun: W-LUN that's supposed to be created precisely for this purpose? I wouldn't object to creating and exporting one of those if we have to and the array doesn't supply it. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
