--- Jeff Garzik <jeff@xxxxxxxxxx> wrote: > Michael Reed wrote: > > > as having a unique WWN should be a product requirement, is an indicator of > > a problem. Shouldn't the proper solution be to have the card repaired? > > Arbitrarily assigning a WWN could mask or introduce other problems, in particular > > with regard to storage connectivity. This is absolutely correct. > If you are an admin suffering from the /common/ problem of missing or > invalid NVRAM, would you rather wait for card repair or get it going > immediately? If you have a SAS HA, and it is missing its NVRAM (erased, etc), then this is something catastrophic, and you have much bigger problems to solve than just to "generate" a WWN. It is extremely, extremely *uncommon* for SAS HA to be missing their manufacturing sector/NVRAM, for products out in the field. Internally bound HAs, for testing, validation, etc, may be missing their MS/NVRAM, but those products are never supposed to leave the testing/validation process, without the "packager" writing their MS/NVRAM into the device. > The standard Linux policy for unique ids like ethernet MAC has been, for > the 98% case where you have a useful MAC from the hardware, of course > use it. For the 2% case, you give the admin solutions for supplying a > useful MAC. So the same rule of principle applies to SAS HAs, to quote: "you give the admin solutions for supplying a useful WWN [was: MAC]" If the SAS HA does NOT have a WWN, then you'll just complain in the kernel log, and not start it up, unless the admin has provided one via kernel/module parameter. In the case where a WWN is missing, it is essential that userspace provides a WWN to the driver, possibly via a kernel/module parameter, and then the driver will use that WWN to assign to the HA. But you MUST NOT establish policy by "generating" it internally in the kernel. I know it would be "cool", but it is unsound. So instead, establish mechanism. > Mirroring decades of ethernet NIC history, the HBA silicon and the > source of the unique id are most often vastly different. Normally it is > a different chip on the same board, but sometimes the unique id source > is not on the same board at all. > > For those reasons and more, Linux users have a LONG history of running > into situations where, for one reason or another, their silicon is fine > but their unique id is not. I've heard them all: > - hw from government auction, had NVRAM intentionally wiped > - hw resale w/ NVRAM wiped by paranoid corporate IT staff > - hw with NVRAM chip missing > - old hw out of warranty > - old dev kit (they rarely ship with useful NVRAM data) > - and plenty more > > We have to behave sanely in the 2% case. "refuse to operate" is just > not an option, when this problem case is so historically clear, and so > easy to work around. > > Linux drivers have to continue operating long after support contracts > run out, long after chip EOL, and sometimes, long after companies go out > of business. This still does not justify "let's generate it in the kernel". If the MS/NVRAM is missing and thus there is no hw WWN, then it should be left to the admin to provide one via a kernel/module option. 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
