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