Re: [PATCH] scsi: scsi_scan purge devices no longer in reported LUN list

[Uday Shankar <ushankar@purestorage.com>]

Hannes, I understand that Brian reached out to you for feedback on this
patch. I still have doubts I'd like to clarify; I quote portions of
your response below.

> Biggest problem is that we currently cannot 'reload' an existing SCSI
> device, as the inquiry data is fixed.

I agree; scsi_probe_and_add_lun called with rescan == SCSI_SCAN_MANUAL
on a LUN for which we already have a struct scsi_device seems to be
essentially no-op. scsi_rescan_device will update VPD, but not other
inquiry data.

> So if we come across things like EMC Clariion which changes the
> inquiry data for LUN0 when mapping devices to the host we don't have
> any other choice but to physically remove the device and rescan it
> again. Which is okay if you run under multipath, but for directly
> accessed devices it'll kill your machine :-(

I don't understand how a "reload" will help in this scenario. I don't
know the specifics of the EMC Clariion behavior, but based on your
description and what I've read in the driver code I assume the device
changes the PDT/PQ fields in the LUN 0 inquiry depending on whether or
not there is storage attached to it. There are two "transitions:"

Attaching storage to LUN 0: We don't save a struct scsi_device for
devices whose PDT/PQ indicates "no storage attached," so when storage
gets attached and PDT/PQ changes, scsi_probe_and_add_lun will act as if
its seeing a new device for the first time. Everything should work.

Detaching storage from LUN 0: The current implementation of target scan
won't pick up the updated inquiry data, sure, but a "reload" can't save
your machine from dying if programs were accessing the LUN 0 volume
directly, can it? Regardless of what the host does, the fact remains
that it can no longer do I/O on the LUN 0 volume. The only thing the
host can control is the particular flavor of errors delivered to these
programs, and the one associated to "device is gone" seems to be most
accurate, and the one that Brian's patch (if it applied to all devices,
not just those with vendor PURE) would deliver.

Overall: we'd like to eliminate the need for manual rescans wherever
possible, and we're willing to revise the patch and/or submit patches
elsewhere as needed to achieve that goal. Please advise.

Thanks,
Uday