On Thu, 2008-07-31 at 21:52 +0300, Gal Rosen wrote: > It won't change the device identification of the existing 10 LUNs, but > it will report UA of "Power on, reset, or bus device reset occured", > then I can send read capacity command. Sending the same email four times doesn't help ... it likely got eaten by linux-scsi each time because you sent a mixed text/html message ... the lists only like plain text But the point is that what happens is highly array dependent ... some will change the id some won't. There's nothing we can say for certain without having knowledge of the array, which really belongs in policy somewhere. James > > -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx] > Sent: Thu 7/31/2008 7:20 PM > To: Gal Rosen > Cc: Stefan Richter; linux-scsi@xxxxxxxxxxxxxxx > Subject: Re: SCSI device rescan, detection of disconnected device,or > switched devices. > > On Thu, 2008-07-31 at 19:09 +0300, Gal Rosen wrote: > > On Thu, 2008-07-31 at 09:15 -0500, James Bottomley wrote: > > > Oh ... you're not really talking about hotplug, which is why > everyone is > > > confused. Hotplug is when you add or remove something from the > bus. > > > What you've done is reconfigure the array. > > > > > > 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). > > > > > > > ?Why? if I keep a mapping between sg devices and device id (Inquiry > page > > 0x83) then I have all the data. > > No we don't, it depends on array policy. Most arrays when told to > take > 10% of space from 10 luns and create a new one won't change the WWN of > the existing 10 LUNS, so we have no idea what just happened or what we > should do about it (incidentally, this is an example of a > reconfiguration you probably wanted to do offline anyway). > > 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