public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Mansfield <patmans@us.ibm.com>
To: Kurt Garloff <garloff@suse.de>,
	James Bottomley <James.Bottomley@steeleye.com>,
	Andrew Morton <akpm@osdl.org>,
	Linux SCSI list <linux-scsi@vger.kernel.org>
Subject: Re: Patches for SCSI scanning
Date: Tue, 20 Apr 2004 10:44:08 -0700	[thread overview]
Message-ID: <20040420104408.B8602@beaverton.ibm.com> (raw)
In-Reply-To: <20040420164238.GT4356@tpkurt.garloff.de>; from garloff@suse.de on Tue, Apr 20, 2004 at 06:42:38PM +0200

On Tue, Apr 20, 2004 at 06:42:38PM +0200, Kurt Garloff wrote:
> Hi Patrick,
> 
> On Tue, Apr 20, 2004 at 09:26:51AM -0700, Patrick Mansfield wrote:
> > On Tue, Apr 20, 2004 at 09:38:00AM -0500, James Bottomley wrote:
> > > Yes, sounds reasonable.  We can do it all with the boot flags now.
> > 
> > max_scsi_luns should default to zero to avoid devices that should be black
> > listed as single lun.
> 
> I strongly disagree.

There were some posts in the past by either Alan or Doug L on this, I
can't find them. Redhat ships with CONFIG_SCSI_MULTI_LUN not set.

> The target should be to blacklist broken devices not working ones. 

I agree that is where we would like to be, but that can break current usage.

> Devices that have multiple LUNs are not, devices that have only one but
> report severals are.
> 
> With max_scsi_luns=1, we would need to "black"list every single multi lun
> device. I very much dislike that idea.

Not individually, just boot with max_scsi_luns=128 or whatever as is done
today for redhat, or boot with default_dev_flags=0x040 (BLIST_SPARSELUN).

> Fortunately, distributors don't do this.

Suse doesn't, Redhat does, I don't know about others.

> > So how can you remove those and maintain compatibilty? The removal should
> > wait for 2.7.
> 
> Expecting your multi lun devices to work with max_scsi_luns=1 is just
> wrong. max_scsi_luns should not default to 1.
> Anyways, BLIST_SPARSELUN will have the side-effect of also working
> around that misconfiguration.

Again that is not compatible with the current 2.6.x code, users with
non-black listed single lun devices will get failures if we default to
max_scsi_luns > 1.

-- Patrick Mansfield

  reply	other threads:[~2004-04-20 17:44 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-18 18:57 Patches for SCSI scanning Kurt Garloff
2004-04-18 23:16 ` James Bottomley
2004-04-20 11:54   ` Kurt Garloff
2004-04-20 12:04     ` Christoph Hellwig
2004-04-20 13:02       ` Kurt Garloff
2004-04-20 14:38     ` James Bottomley
2004-04-20 16:03       ` Kurt Garloff
2004-04-20 16:08         ` James Bottomley
2004-04-21 13:48           ` Kurt Garloff
2004-04-21 15:36             ` James Bottomley
2004-04-21 13:45         ` Kurt Garloff
2004-04-21 14:10           ` PATCH 1/5: scsi-scan-deprecate-forcelun Kurt Garloff
2004-04-21 14:12           ` PATCH 2/5: scsi-scan-blist_replun Kurt Garloff
2004-04-21 15:14             ` Christoph Hellwig
2004-04-21 15:30               ` Kurt Garloff
2004-04-21 16:03               ` Kurt Garloff
2004-04-21 14:13           ` PATCH 3/5: scsi-scan-no-offl-pq-notcon Kurt Garloff
2004-04-21 14:14           ` PATCH 4/5: scsi-scan-dont-att-pq-notcon Kurt Garloff
2004-04-21 15:02             ` Christoph Hellwig
2004-04-21 15:24               ` Kurt Garloff
2004-04-21 15:33                 ` Mike Anderson
2004-04-21 15:33                 ` Christoph Hellwig
2004-04-21 16:08                   ` Kurt Garloff
2004-04-21 16:18                     ` James Bottomley
2004-04-21 16:55                       ` Patrick Mansfield
2004-04-21 22:51                         ` Kurt Garloff
2004-04-22 20:39                           ` Patrick Mansfield
2004-04-22 20:45                             ` James Bottomley
2004-04-21 16:58                       ` Kurt Garloff
2004-04-21 16:16                   ` Kurt Garloff
2004-04-21 15:40             ` James Bottomley
2004-04-21 14:14           ` PATCH 5/5: scsi-scan-inq-timeout Kurt Garloff
2004-04-21 20:24             ` Patrick Mansfield
2004-04-21 22:48               ` Kurt Garloff
2004-04-21 23:49                 ` Patrick Mansfield
2004-04-20 16:26       ` Patches for SCSI scanning Patrick Mansfield
2004-04-20 16:42         ` Kurt Garloff
2004-04-20 17:44           ` Patrick Mansfield [this message]
2004-04-21 13:52             ` Kurt Garloff
2004-04-20 10:24 ` Fabien Salvi
  -- strict thread matches above, loose matches on Subject: below --
2004-04-22  4:09 Martin Peschke3
2004-04-22  4:17 Martin Peschke3

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=20040420104408.B8602@beaverton.ibm.com \
    --to=patmans@us.ibm.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=akpm@osdl.org \
    --cc=garloff@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    /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