David Miller wrote:
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
--- James Bottomley [EMAIL PROTECTED] wrote:
For the record, what the current in-kernel aic94xx driver does for this
case is allow a parameter override to specify the WWN in the case where
the card burned in one has gone missing or is corrupt. I think this is
the correctly balanced approach
--- Jeff Garzik [EMAIL PROTECTED] 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
--- Jeff Garzik [EMAIL PROTECTED] 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 ...).
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
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
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
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
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
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
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
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 ...).
On Wed, 2007-10-03 at 15:17 -0700, David Miller wrote:
From: Luben Tuikov [EMAIL PROTECTED]
Date: Wed, 3 Oct 2007 15:08:48 -0700 (PDT)
Your want to get their card working way of view is very
simplistic to justify generating and assigning SAS WWN in the kernel.
This is the job of the
On Fri, 2007-10-05 at 15:11 -0700, David Miller wrote:
From: James Bottomley [EMAIL PROTECTED]
Date: Fri, 05 Oct 2007 18:09:06 -0400
For the record, what the current in-kernel aic94xx driver does for this
case is allow a parameter override to specify the WWN in the case where
the card
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
David Miller wrote:
I think providing both possibilities (kernel auto-generated and user
specified) is appropriate.
And that's been my plan from day one... which is remarkably a lot like
the behavior of several net drivers. :)
* attempt to read WWN during module load
* admin may
From: Jeff Garzik [EMAIL PROTECTED]
Date: Fri, 05 Oct 2007 18:41:40 -0400
And that's been my plan from day one... which is remarkably a lot like
the behavior of several net drivers. :)
* attempt to read WWN during module load
* admin may optionally choose to manually specify OR
David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Fri, 05 Oct 2007 18:41:40 -0400
And that's been my plan from day one... which is remarkably a lot like
the behavior of several net drivers. :)
* attempt to read WWN during module load
* admin may optionally choose to manually
Jeff Garzik wrote:
Luben Tuikov wrote:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
The admin will have the option to auto-generate a WWN, should they so
desire.
What does that mean? auto-generate? By whom?
The admin tells the kernel module to auto-generate a WWN, and the kernel
module
Jeff Garzik wrote:
Luben Tuikov wrote:
Do you mean:
The admin will have the option to SPECIFY(SET) a WWN, should they
sodesire.
OR do you mean:
The admin will have the option to HAVE THE KERNEL auto-generate a WWN,
should they so desire.
Both. It is up to admin policy to
Michael Reed wrote:
Jeff Garzik wrote:
Luben Tuikov wrote:
Do you mean:
The admin will have the option to SPECIFY(SET) a WWN, should they
sodesire.
OR do you mean:
The admin will have the option to HAVE THE KERNEL auto-generate a WWN,
should they so desire.
Both. It is up to
Douglas Gilbert wrote:
Jeff Garzik wrote:
Luben Tuikov wrote:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
The admin will have the option to auto-generate a WWN, should they so
desire.
What does that mean? auto-generate? By whom?
The admin tells the kernel module to auto-generate a WWN, and
The generation algorithm is whatever makes people happy. I would
probably pick a fixed prefix like 0x6C 0x69 0x63 (lin), something that
doesn't conflict with IEEE org ids for a long time to come. Then,
get_random_bytes() or hash some useful machine characteristics for the
rest of the
Matthew Jacob wrote:
The generation algorithm is whatever makes people happy. I would
probably pick a fixed prefix like 0x6C 0x69 0x63 (lin), something that
doesn't conflict with IEEE org ids for a long time to come. Then,
get_random_bytes() or hash some useful machine characteristics for the
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Matthew Jacob wrote:
The generation algorithm is whatever makes people happy. I would
probably pick a fixed prefix like 0x6C 0x69 0x63 (lin), something that
doesn't conflict with IEEE org ids for a long time to come. Then,
get_random_bytes() or
Luben Tuikov wrote:
What is needed is persistence, regardless of reboots of what OS
is running on the host CPU/system. SAS WWNs are properties of
the SAS target/initiator port, they are not properties of when
the host system was booted, or what OS is running on it.
As part of the previously
From: Luben Tuikov [EMAIL PROTECTED]
Date: Wed, 3 Oct 2007 15:08:48 -0700 (PDT)
Your want to get their card working way of view is very
simplistic to justify generating and assigning SAS WWN in the kernel.
This is the job of the manufacturer/packager, not the host OS.
When you are thousands
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
What is needed is persistence, regardless of reboots of what OS
is running on the host CPU/system. SAS WWNs are properties of
the SAS target/initiator port, they are not properties of when
the host system was booted, or what OS
--- David Miller [EMAIL PROTECTED] wrote:
From: Luben Tuikov [EMAIL PROTECTED]
Date: Wed, 3 Oct 2007 15:08:48 -0700 (PDT)
Your want to get their card working way of view is very
simplistic to justify generating and assigning SAS WWN in the kernel.
This is the job of the
But having a WWN generator in the kernel, although not terribly
difficult to write, makes it possible to create an inconsistent
storage domain. It is that possibility which troubles me,
due to the intention of SAS WWNs.
But one should make sure that you *do* create a consistent storage
Matthew Jacob wrote:
A much better choice is to get real stamped serial number WWNs. I also
hold with some of the other folks on this discussion that some of this
is policy that the admin should be allowed to choose. After they've
segmented the company's main fabric by choosing unwisely and
On Wed, Oct 03, 2007 at 08:23:14PM -0700, Matthew Jacob wrote:
For smaller bit spaces like 64 bit WWNs, you cannot, as you correctly
point out, generate reliably unique numbers all by youself. The
closest you could probably come is using a type 5 WWN with a known
single OUI and then use
--- Jeff Garzik [EMAIL PROTECTED] 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
Luben Tuikov wrote:
This still does not justify let's generate it in the kernel.
Once an admin specifies to use an alternate WWN provision, the method
used to obtain that WWN is an implementation detail and irrelevant.
Jeff
-
To unsubscribe from this list: send the line
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
This still does not justify let's generate it in the kernel.
Once an admin specifies to use an alternate WWN provision, the method
used to obtain that WWN is an implementation detail and irrelevant.
But you're arguing that the
Luben Tuikov wrote:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
This still does not justify let's generate it in the kernel.
Once an admin specifies to use an alternate WWN provision, the method
used to obtain that WWN is an implementation detail and irrelevant.
But you're
Luben Tuikov wrote:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
This still does not justify let's generate it in the kernel.
Once an admin specifies to use an alternate WWN provision, the method
used to obtain
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
This still does not justify let's generate it in the kernel.
Once an admin specifies to use an
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
This still does not justify let's generate it in the kernel.
Once an admin specifies to use an
Luben Tuikov wrote:
--- Jeff Garzik [EMAIL PROTECTED] wrote:
The admin will have the option to auto-generate a WWN, should they so
desire.
What does that mean? auto-generate? By whom?
The admin tells the kernel module to auto-generate a WWN, and the kernel
module happily obliges.
The
Luben Tuikov wrote:
Do you mean:
The admin will have the option to SPECIFY(SET) a WWN, should they so
desire.
OR do you mean:
The admin will have the option to HAVE THE KERNEL auto-generate a WWN,
should they so desire.
Both. It is up to admin policy to decide if they wish to use
The popular solutions I've seen are:
1) Random bytes, or fixed id + random bytes. Even on a worldwide net,
collisions are highly unlikely.
The problem is that the random bytes are not necessarily random; especially
not at boot:
get_random_bytes gets its randomness from the entropy pool.
Is there an accepted way to generate a SAS address, when the adapter
does not supply one (NVRAM invalid or missing, etc.)?
Unless somebody complains, I was just planning to use
get_random_bytes(). But maybe Linux has an IEEE id we can use, to make
the practice a bit more legitimate and avoid
Uh, although this may work very well for small constrained configs, as one
who debugs larger environments (and things always grow or get connected in
ways you don't expect), depending on a random number for uniqueness makes
me very unsettled. Debugging that small-percentage potential, when/if it
James Smart wrote:
Uh, although this may work very well for small constrained configs, as one
who debugs larger environments (and things always grow or get connected in
ways you don't expect), depending on a random number for uniqueness makes
me very unsettled. Debugging that small-percentage
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 0xFF you
could at least guarantee that you didn't conflict with
Jeff Garzik wrote:
James Smart wrote:
Uh, although this may work very well for small constrained configs, as one
who debugs larger environments (and things always grow or get connected in
ways you don't expect), depending on a random number for uniqueness makes
me very unsettled. Debugging
Matthew Wilcox wrote:
On Thu, Sep 27, 2007 at 09:16:13AM -0500, [EMAIL PROTECTED] 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...
Michael Reed wrote:
Matthew Wilcox wrote:
On Thu, Sep 27, 2007 at 09:16:13AM -0500, [EMAIL PROTECTED] 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
Michael Reed wrote:
Jeff Garzik wrote:
James Smart wrote:
Uh, although this may work very well for small constrained configs, as one
who debugs larger environments (and things always grow or get connected in
ways you don't expect), depending on a random number for uniqueness makes
me very
Matthew Wilcox wrote:
On Thu, Sep 27, 2007 at 09:16:13AM -0500, [EMAIL PROTECTED] 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
Michael Reed wrote:
Record the WWN of your SAS / FC port so that if/when it goes missing you
can put it back? Have spares on site?
Linux: not just for million dollar data centers any more :)
(sorry, couldn't resist :))
More seriously, SAS will be making an increasing appearance on
52 matches
Mail list logo
