From: Jeff Garzik <jeff@garzik.org>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Patrick_Boyd@Dell.com, James.Smart@Emulex.Com,
linux-scsi@vger.kernel.org
Subject: Re: generating a Linux WWN?
Date: Thu, 27 Sep 2007 18:48:14 -0400 [thread overview]
Message-ID: <46FC332E.2040001@garzik.org> (raw)
In-Reply-To: <20070927144649.GV3899@parisc-linux.org>
Matthew Wilcox wrote:
> On Thu, Sep 27, 2007 at 09:16:13AM -0500, Patrick_Boyd@Dell.com wrote:
>> Unfortunately, it looks like IEEE doesn't have any OID's registered for
>> Linux or other reserved areas
>> (http://standards.ieee.org/regauth/oui/oui.txt). However, it does look
>> like they go in order... so maybe if you used an OID of 0xFFFFFF you
>> could at least guarantee that you didn't conflict with any company's SAS
>> WWNs.
>
> It's something that happens frequently enough that we should come up
> with a proper way of handling this. I heard a story of someone at HP
> taking an old computer, reading the MAC address from the motherboard,
> then snapping the board in half. I suppose if you're going to use a MAC
> address from a 10Mbit ethernet card for a SAS WWN, there's no chance of
> conflict, but still ... 3com might choose to do the same thing, and then
> we're in trouble.
>
> I don't have a good solution for WWN assignment. Even if we get a
> 24-bit OID assignment for 'software use' or something, how do we control
> the use withi the SAN to be sure we get no overlapping WWNs?
To a perfectionist, there are no good answers besides "try your best."
The popular solutions I've seen are:
1) Random bytes, or fixed id + random bytes. Even on a worldwide net,
collisions are highly unlikely.
2) [pseudo-]hash of reasonably static properties of your platform.
3) Admin makes a site-specific decision, blending cases #1 and #2 with
other schemes such as site-defined numbering.
In the ethernet world, all the drivers permit programmable MAC
addresses, and many generate a random MAC if one is unavailable through
other means. In practice this is deployed rarely, though things like
bonding and seamless failover are making much more use of programmable
MAC addresses than ever before.
For case #2, one might consider creating a WWN for an ATA device that
lacks one (they often do, even with a defined WWN field), by hashing the
vendor id, firmware rev, and media serial number together. But even
with such hueristics, persistence and uniqueness are difficult to recreate.
With either case 1 or 2 -- both have seen success in the field -- you
are essentially relying on luck after a certain point. And that's life.
Jeff
next prev parent reply other threads:[~2007-09-27 22:48 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-27 10:04 generating a Linux WWN? Jeff Garzik
2007-09-27 13:55 ` Michael Reed
2007-09-27 14:04 ` James Smart
2007-09-27 14:16 ` Patrick_Boyd
2007-09-27 14:46 ` Matthew Wilcox
2007-09-27 15:07 ` Michael Reed
2007-09-27 15:12 ` Michael Reed
2007-09-27 23:40 ` Jeff Garzik
2007-09-27 22:48 ` Jeff Garzik [this message]
2007-10-01 10:56 ` Andi Kleen
2007-09-27 14:19 ` Jeff Garzik
2007-09-27 14:29 ` Michael Reed
2007-09-27 15:30 ` Douglas Gilbert
2007-09-27 22:32 ` Jeff Garzik
2007-09-27 23:12 ` Jeff Garzik
2007-10-02 23:47 ` Luben Tuikov
2007-10-03 0:35 ` Jeff Garzik
2007-10-03 3:45 ` Luben Tuikov
2007-10-03 4:15 ` Jeff Garzik
2007-10-03 5:12 ` Luben Tuikov
2007-10-03 5:25 ` Jeff Garzik
2007-10-03 5:31 ` Luben Tuikov
2007-10-03 5:45 ` Jeff Garzik
2007-10-03 14:59 ` Douglas Gilbert
2007-10-03 16:16 ` Jeff Garzik
2007-10-03 18:02 ` Matthew Jacob
2007-10-03 18:09 ` Jeff Garzik
2007-10-03 19:44 ` Luben Tuikov
2007-10-03 20:25 ` Jeff Garzik
2007-10-03 22:08 ` Luben Tuikov
2007-10-03 22:17 ` David Miller
2007-10-04 0:11 ` Luben Tuikov
2007-10-04 3:23 ` Matthew Jacob
2007-10-04 3:27 ` Jeff Garzik
2007-10-04 3:33 ` Matthew Wilcox
2007-10-05 22:09 ` James Bottomley
2007-10-05 22:11 ` David Miller
2007-10-05 22:14 ` James Bottomley
2007-10-05 22:17 ` David Miller
2007-10-05 22:41 ` Jeff Garzik
2007-10-05 22:49 ` David Miller
2007-10-05 22:52 ` Jeff Garzik
2007-10-06 14:11 ` James Bottomley
2007-10-06 14:36 ` Jeff Garzik
2007-10-06 15:04 ` James Bottomley
2007-10-06 15:23 ` Jeff Garzik
2007-10-06 15:33 ` James Bottomley
2007-10-06 15:42 ` Jeff Garzik
2007-10-08 18:42 ` Luben Tuikov
2007-10-07 2:48 ` David Miller
2007-10-08 15:41 ` Michael Reed
2007-10-08 18:34 ` Luben Tuikov
2007-10-07 2:46 ` David Miller
2007-10-08 18:18 ` Luben Tuikov
2007-10-03 5:38 ` Luben Tuikov
2007-10-03 5:47 ` Jeff Garzik
2007-10-03 15:33 ` Michael Reed
2007-10-03 16:02 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46FC332E.2040001@garzik.org \
--to=jeff@garzik.org \
--cc=James.Smart@Emulex.Com \
--cc=Patrick_Boyd@Dell.com \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox