Re: generating a Linux WWN?
On Fri, 2007-10-05 at 15:17 -0700, David Miller wrote: From: James Bottomley [EMAIL PROTECTED] Date: Fri, 05 Oct 2007 18:14:48 -0400 On Fri, 2007-10-05 at 15:11 -0700, David Miller wrote: auto_wwn=1 or somthing like that I'd far prefer override_wwn = fully specific WWN since I assume auto_wwn means get the kernel to generate one? I think providing both possibilities (kernel auto-generated and user specified) is appropriate. 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. I'd rather not give an interface which seems like a magic bullet but which is a potential time bomb in a cluster (particularly when it has such a long fuse). James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
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). Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
On Sat, 2007-10-06 at 10:36 -0400, Jeff Garzik 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). So your use case for this feature is a savvy system admin whose going to turn it on for a one time boot while he figures out what the correct WWN override is and who will then immediately set the system up to override properly on its next boot? That's what seems to me to be the unlikely scenario. I know when I'm under the gun to solve a problem I'll do the first thing I find that actually works. So I'd rather only expose an interface that allows them to get it right. If you remember Rusty's guide to interfaces, this is a level 14 easy to misuse interface: The obvious use is wrong; since the obvious use is to put it in module parameters and have the problem go away (for now ...). Actually, I could be harsher and say it's level 17 There's no correct use because statistically every time you use it, you expose yourself to potential duplicate WWNs. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
James Bottomley wrote: If you remember Rusty's guide to interfaces, this is a level 14 easy to misuse interface: The obvious use is wrong; since the obvious use is to put it in module parameters and have the problem go away (for now ...). Actually, I could be harsher and say it's level 17 There's no correct use because statistically every time you use it, you expose yourself to potential duplicate WWNs. Now that you have said there's no correct use you have managed to logic yourself into silly-land. That is utterly specious logic when duplicate WWNs are quite unlikely, and furthermore -- as demonstrated by use in network drivers -- use of the feature itself is not the common case. Field experience directly contradicts this entire line of reasoning. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
On Sat, 2007-10-06 at 11:23 -0400, Jeff Garzik wrote: James Bottomley wrote: If you remember Rusty's guide to interfaces, this is a level 14 easy to misuse interface: The obvious use is wrong; since the obvious use is to put it in module parameters and have the problem go away (for now ...). Actually, I could be harsher and say it's level 17 There's no correct use because statistically every time you use it, you expose yourself to potential duplicate WWNs. Now that you have said there's no correct use you have managed to logic yourself into silly-land. That is utterly specious logic when duplicate WWNs are quite unlikely, and furthermore -- as demonstrated by use in network drivers -- use of the feature itself is not the common case. Field experience directly contradicts this entire line of reasoning. OK, give me your use case. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
James Bottomley wrote: On Sat, 2007-10-06 at 11:23 -0400, Jeff Garzik wrote: James Bottomley wrote: If you remember Rusty's guide to interfaces, this is a level 14 easy to misuse interface: The obvious use is wrong; since the obvious use is to put it in module parameters and have the problem go away (for now ...). Actually, I could be harsher and say it's level 17 There's no correct use because statistically every time you use it, you expose yourself to potential duplicate WWNs. Now that you have said there's no correct use you have managed to logic yourself into silly-land. That is utterly specious logic when duplicate WWNs are quite unlikely, and furthermore -- as demonstrated by use in network drivers -- use of the feature itself is not the common case. Field experience directly contradicts this entire line of reasoning. OK, give me your use case. I already have, in this thread. Jeff - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
From: James Bottomley [EMAIL PROTECTED] Date: Sat, 06 Oct 2007 09:11:10 -0500 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). If you have at least one ethernet NIC, you have at least one globally unique MAC address, which is 6 bytes of uniqueness to draw from. I'm sure there are countless other possibilities. I think the SAN issue is way overstated. Sure it's real, but so are SHA conflicts in the kernel GIT repository. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: generating a Linux WWN?
From: James Bottomley [EMAIL PROTECTED] Date: Sat, 06 Oct 2007 10:04:55 -0500 If you remember Rusty's guide to interfaces, this is a level 14 easy to misuse interface: The obvious use is wrong; since the obvious use is to put it in module parameters and have the problem go away (for now ...). Actually, I could be harsher and say it's level 17 There's no correct use because statistically every time you use it, you expose yourself to potential duplicate WWNs. Every time you use GIT you expose yourself to potential duplicate SHAs which will corrupt the tree. This argument borders on lunacy, give it up :-) - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
