On Sun, 2009-05-03 at 12:45 -0700, David Miller wrote: > From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > Date: Sat, 02 May 2009 23:10:33 -0500 > > > I Understand, that's why it's like the Fibre persistent bindings. There > > are, unfortunately, good reasons why it can't be used as the target id, > > but if we just exported the id, udev can create a device node using it > > and you can mount via that device node in an across boot consistent > > manner ... will that do? > > I see no reason why you wouldn't want to use known perfectly good > persistent SCSI target IDs computed by the card. The technical reason is that the lifetime rules for the IDs in the card firmware don't match the lifetime rules in the mid layer and target ids in the mid layer have to be unique. It's not a problem absent hotplug, but SAS is a hotplug bus. ... unplug from phy1 and plug immediately into phy2 is the most pathological case for this. We could take the fusion target ID as a hint and only overrule it if it would cause duplicate IDs, so get it right 95% of the time ... but I can just bet we'd see a large number of complaints about the surprise factor involved in the 5% of cases where we had to allocate a new id. > It doesn't make any sense, and it is inconsistent with how any > other piece of code in the world handles these values provided > by the card. We can export the values provided by the card, and udev can create a device node based on them, thus giving apparent persistence to device nodes with this, so that would solve the boot from and mount from issue. 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
