Re: SCSI device rescan, detection of disconnected device, or switched devices.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



James Bottomley wrote:
On Thu, 2008-07-31 at 19:59 +0400, Vladislav Bolkhovitin wrote:
James Bottomley wrote:
Most of the hotplug we do depends on the transport model (because what's
on the transport is changing).  Array reconfiguration has no hotplug
event because SAM-3 has no real way of passing the information
asynchronously.  The best it can do is Unit Attention/reported luns data
has changed (asc=0x3f/ascq=0xe) on the next command.

The problem is that there's no way to process the event correctly even
when we get it.  All we can do is issue another report LUNS command and
compare.  However, just because it looks like a single LUN disappeared
doesn't mean the others weren't permuted or altered in some way (which
data we cannot get).
But why don't do what's possible to do and for what there is complete information: add new LUN for new LUN and delete deleted LUN for reported luns data has changed UA? As well as get new capacity for a LU on capacity data has changed UA after, e.g., new space added to it?

Well, feel free to submit a patch, but it's an incredible mine field.
We certainly can't do something that builds a trap for users (as in a
policy which gets it right 10% of the time and wrong 90% of the time) so
I'm strongly inclined to feel array reconfiguration is a manual process.
If you think you can do it online, we don't panic or throw a spanner in
the works, but we wait until you tell us what you did, but you'd be well
advised to do it offline.

The point is that we can't distinguish LUN added from LUN split or space
reapportioned or something ... even LUN renumbered would be seen as a
remove followed by an add.

Sure, in cases, where it is impossible based of INQUIRY data unambiguously determine that, it's better don't do anything. But in cases if it is possible, which is true for most modern devices, it can be handled properly.

Vlad

--
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux