--- Jeff Garzik <jeff@xxxxxxxxxx> wrote: > James Bottomley wrote: > > My problem with auto generated is that it's provably impossible to > > generate globally unique numbers for WWNs without some internal source > > of uniqueness (I know sparcs have this in their serial number, but most > > PCs unfortunately don't). > > > > I know the auto generated number can be statistically reasonably unique, > > but sysadmins are lazy people. If they run into this problem, they'll > > take the knob with the on/off switch rather than the think about the > > problem and specify the full WWN; and then, being busy people, they'll > > forget about it as "problem solved". When they do this, statistically > > (and probably years later) there will be a cluster reboot where the > > entire SAN simply collapses and no-one knows why ... the poor SAN > > administrator will likely spend weeks working out the problem is. > > Why, if we give lazy administrators root access, that's all they'll use, > and they will just think "problem solved" until a serious security issue > arises that takes down the cluster. > > See how silly and un-Linux that logic is? In Linux, the admin has the > power to make stupid decisions -- or to make informed decisions that > disagree your rigid "an admin should never do that" line of thought. > It's their hardware. > > You're also using the 1% case of a 1% case of a 1% case to argue against > a feature that is useful in making things Just Work(tm). What he's arguing about is the _capability_ for a node in a SAN to *(auto)generate* WWN and assign it to itself (at every reboot, etc). This is considered a _rogue_ node and *no* SAN architect or admin will tolerate such a node. The problem here is NOT the _capability_ to assign a WWN. Admin does have the capability to assign (if missing) and/or override (if present) a WWN currently with aic94xx driver. This is fine. The problem is "(auto)generate". Think of SANs. 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
