public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: David Miller <davem@davemloft.net>
Cc: ltuikov@yahoo.com, jeff@garzik.org, lydianconcepts@gmail.com,
	mdr@sgi.com, James.Smart@emulex.com, linux-scsi@vger.kernel.org
Subject: Re: generating a Linux WWN?
Date: Fri, 05 Oct 2007 18:09:06 -0400	[thread overview]
Message-ID: <1191622146.3475.51.camel@localhost.localdomain> (raw)
In-Reply-To: <20071003.151729.95504687.davem@davemloft.net>

On Wed, 2007-10-03 at 15:17 -0700, David Miller wrote:
> From: Luben Tuikov <ltuikov@yahoo.com>
> 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 of miles away from the data center and lose all
> of your storage and therefore can't boot correctly because the WWN
> info is corrupted, you won't have this unbelievably fascist attitude
> about this problem.
> 
> Give people an _OPTION_!
> 
> This is about as anti-social as when the Intel folks refused to
> themselves put in a driver option to try to use an eepro100 card even
> if the EEPROM was corrupted and had a bad checksum.
> 
> For the person who hits this, it's a big issue to have a way to still
> try to bring things up.
> 
> If you don't provide this, you want people to suffer more than
> necessary when something goes wrong, and that by definition makes you
> an asshole.

The tenor of this debate is becoming slightly heated, so it needs to
cool down a notch.

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 to the problem.

For the record, I pretty much agree completely with Luben's position on
this:  I want to allow the user a method to correct any problem (i.e.
supply a WWN override).  However, I also want them to think about the
issue before they do this.  What I really don't want is the driver
silently correcting what it thinks to be a defective WWN and generating
its own replacement because that's a recipe for disaster on a SAN (SANs
are a lot less robust than networks to duplicate MAC addresses: because
of the way expander routing is done, you can possibly collapse the
entire SAN with duplicate WWNs).

So, the procedure for a SAS card should be:

     1. Obtain the WWN from a device specific storage method (like
        flash)
     2. Replace this with a passed in command line parameter if one
        exists
     3. refuse to attach if there's still no valid WWN and give an
        explicit method saying what the problem is (and possibly how to
        fix it)

James



  parent reply	other threads:[~2007-10-05 22:09 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
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 [this message]
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=1191622146.3475.51.camel@localhost.localdomain \
    --to=james.bottomley@steeleye.com \
    --cc=James.Smart@emulex.com \
    --cc=davem@davemloft.net \
    --cc=jeff@garzik.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=ltuikov@yahoo.com \
    --cc=lydianconcepts@gmail.com \
    --cc=mdr@sgi.com \
    /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