--- James Bottomley <James.Bottomley@xxxxxxxxxxxx> wrote: > > For the record, what the current in-kernel aic94xx driver does for this > case is allow a parameter override to specify the WWN in the case where > the card burned in one has gone missing or is corrupt. I think this is > the correctly balanced approach to the problem. > > For the record, I pretty much agree completely with Luben's position on > this: I want to allow the user a method to correct any problem (i.e. > supply a WWN override). However, I also want them to think about the > issue before they do this. What I really don't want is the driver > silently correcting what it thinks to be a defective WWN and generating > its own replacement because that's a recipe for disaster on a SAN (SANs > are a lot less robust than networks to duplicate MAC addresses: because > of the way expander routing is done, you can possibly collapse the > entire SAN with duplicate WWNs). > > So, the procedure for a SAS card should be: > > 1. Obtain the WWN from a device specific storage method (like > flash) > 2. Replace this with a passed in command line parameter if one > exists > 3. refuse to attach if there's still no valid WWN and give an > explicit method saying what the problem is (and possibly how to > fix it) That is absolutely correct. If a node in a SAN doesn't come up, the SAN admin will inspect the kernel log and find out that the driver failed to attach due to a missing WWN. This is a grave condition. In enterprise, if one component is compromised, then the whole system should fail and be brought to admin's attention. The admin may decide to replace this card with a working one, or ask the Storage Manager to generate a temporary WWN (which could be the next machine over), or if the admin themselves maintain the SAN, they can generate a temporary WWN. But it is imperative that the admin immediately knows of the fact that a node in the SAN has experienced a problem and cannot read its WWN. Alternatively, if the SAN is zoned, then the _rogue_ node who autogenerated its WWN will be rejected access to the SAN. A node which autogenerates WWNs is considered a security risk and a rogue node. Luben - 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
