Re: generating a Linux WWN?

Luben Tuikov
2007-10-02T23:47:41Z

--- Jeff Garzik <jeff@garzik.org> 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