From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luben Tuikov Subject: Re: generating a Linux WWN? Date: Mon, 8 Oct 2007 11:18:56 -0700 (PDT) Message-ID: <423911.99564.qm@web31805.mail.mud.yahoo.com> References: <1191622146.3475.51.camel@localhost.localdomain> Reply-To: ltuikov@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Return-path: Received: from web31805.mail.mud.yahoo.com ([68.142.207.68]:37403 "HELO web31805.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753573AbXJHSS5 (ORCPT ); Mon, 8 Oct 2007 14:18:57 -0400 In-Reply-To: <1191622146.3475.51.camel@localhost.localdomain> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: James Bottomley , David Miller Cc: ltuikov@yahoo.com, jeff@garzik.org, lydianconcepts@gmail.com, mdr@sgi.com, James.Smart@emulex.com, linux-scsi@vger.kernel.org --- James Bottomley 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 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) That is absolutely correct. If a node in a SAN doesn't come up, the SAN admin will inspect the kernel log and find out that the driver failed to attach due to a missing WWN. This is a grave condition. In enterprise, if one component is compromised, then the whole system should fail and be brought to admin's attention. The admin may decide to replace this card with a working one, or ask the Storage Manager to generate a temporary WWN (which could be the next machine over), or if the admin themselves maintain the SAN, they can generate a temporary WWN. But it is imperative that the admin immediately knows of the fact that a node in the SAN has experienced a problem and cannot read its WWN. Alternatively, if the SAN is zoned, then the _rogue_ node who autogenerated its WWN will be rejected access to the SAN. A node which autogenerates WWNs is considered a security risk and a rogue node. Luben