public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Mansfield <patmans@us.ibm.com>
To: "Philip R. Auld" <pauld@egenera.com>
Cc: Steven Dake <sdake@mvista.com>, linux-scsi@vger.kernel.org
Subject: Re: [announce] scsi_id 0.1 - generate unique scsi id
Date: Mon, 27 Oct 2003 07:27:33 -0800	[thread overview]
Message-ID: <20031027072733.A20720@beaverton.ibm.com> (raw)
In-Reply-To: <20031027091655.B4263@vienna.EGENERA.COM>; from pauld@egenera.com on Mon, Oct 27, 2003 at 09:16:55AM -0500

Philip -

On Mon, Oct 27, 2003 at 09:16:55AM -0500, Philip R. Auld wrote:

> In my experience code page 0x83 by itself is not always enough. There 
> are high-end devices that don't return the results correctly. This leads 
> to false negatives (which are safer than false positives, of course, but 
> make multipath useless). I think in all of these auto-mp detection schemes 
> there needs to be some mechanism for dealing with the quirks of different 
> machine types. In userspace it should not be hard to have a table of some 
> kind to tell such programs how to compare the results. This can also depend 
> on how the system is configured as well so that adds another level of 
> complexity.

The above generally applies even without multi-path (i.e. for use with
udev).

The scsi_id program is setup to have a callout program, I did not complete
coding it, mainly because I do not have any devices that require a
callout.

And, It is not clear if the specific code called should be a separate
program or a new function. A separate program can be released independent
of scsi_id, but that means we will need common or duplicated code: mainly
for the sg_io usage, and decoding of the result, especially the sense
data.

There is a /etc/scsi_id.config file, where devices can be optionally black
or white listed, and callout programs can be specified. This is all done
based on the vendor and optionally model (product) of the scsi device.

The config file can also be used to set global options.

-- Patrick Mansfield

  reply	other threads:[~2003-10-27 15:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-21 23:58 [announce] scsi_id 0.1 - generate unique scsi id Patrick Mansfield
2003-10-22 14:31 ` Christoph Hellwig
2003-10-22  7:42   ` Daniel Stekloff
2003-10-22 14:46     ` Christoph Hellwig
2003-10-22  8:05       ` Daniel Stekloff
2003-10-22 15:52         ` Matthew Wilcox
2003-10-22 16:15           ` Patrick Mansfield
2003-10-22 16:23             ` Christoph Hellwig
2003-10-23  7:33             ` Jes Sorensen
2003-10-24 21:33 ` Steven Dake
2003-10-27 14:16   ` Philip R. Auld
2003-10-27 15:27     ` Patrick Mansfield [this message]
2003-10-27 17:06       ` Philip R. Auld
2003-10-27 17:31         ` Patrick Mansfield
2003-10-28 14:19           ` Philip R. Auld
2003-10-28 15:06             ` Patrick Mansfield
2003-10-28 15:40               ` Philip R. Auld
2003-10-28 16:29                 ` Patrick Mansfield

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=20031027072733.A20720@beaverton.ibm.com \
    --to=patmans@us.ibm.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pauld@egenera.com \
    --cc=sdake@mvista.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