All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: James Bottomley <jbottomley@parallels.com>
Cc: Hannes Reinecke <hare@suse.de>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Ewan Milne <emilne@redhat.com>,
	Ren Mingxin <renmx@cn.fujitsu.com>,
	Bart van Assche <bvanassche@acm.org>
Subject: Re: [PATCHv2 0/7] Limit overall SCSI EH runtime
Date: Tue, 2 Jul 2013 10:58:09 -0400	[thread overview]
Message-ID: <20130702145809.GA19005@logfs.org> (raw)
In-Reply-To: <1372747024.2385.71.camel@dabdike>

On Tue, 2 July 2013 06:37:05 +0000, James Bottomley wrote:
> 
> I don't understand what you're getting at.  In a dual HBA situation,
> whether the second HBA is implicated or not depends on configuration and
> what the first HBA is doing. If it's just passively lost device state,
> then the second HBA should continue just fine.  If the insane HBA is

If the problem is an insane drive instead of an insane HBA, both HBAs
will be in roughly the same state at roughly the same time - assuming
they both send commands to the insane drive.  If they now go into
error handling and effectively shut off all the sane drives at roughly
the same time, the user is ****ed.

And we shouldn't require the user to buy better hardware.  The whole
point of a redundant setup is that your plane doesn't crash to the
ground when one of your two engines fails.  If regulations required
perfect engines, you wouldn't be flying to conferences.  They require
decent engines and enough redundancy that any one can fail at any
moment.

Computer systems are no different.  We can construct a robust system
from individually less robust components.  Requiring perfect
components would be ludicrous.  Having a system design where one
faulty component will reliably bring the system down is equally
ludicrous.  Sadly that is also the state of today's scsi stack.

This is not a theoretical problem, btw.  We currently carry some
patches to solve it for us.  They are not applicable for mainline in
their current state - we support a lot less hardware diversity.  But
trust me, we didn't create them on a whim. ;)

Jörn

--
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-07-02 16:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-01  6:50 [PATCHv2 0/7] Limit overall SCSI EH runtime Hannes Reinecke
2013-07-01  6:50 ` [PATCH 1/7] dpt_i2o: Remove DPTI_STATE_IOCTL Hannes Reinecke
2013-07-01  6:50 ` [PATCH 2/7] dpt_i2o: return SCSI_MLQUEUE_HOST_BUSY when in reset Hannes Reinecke
2013-07-01  6:50 ` [PATCH 3/7] advansys: Remove 'last_reset' references Hannes Reinecke
2013-07-01  6:50 ` [PATCH 4/7] tmscsim: Move 'last_reset' into host structure Hannes Reinecke
2013-07-01  6:50 ` [PATCH 5/7] dc395: Move 'last_reset' into internal " Hannes Reinecke
2013-07-01  6:50 ` [PATCH 6/7] scsi: remove check for 'resetting' Hannes Reinecke
2013-07-01  6:50 ` [PATCH 7/7] scsi: Add 'eh_deadline' to limit SCSI EH runtime Hannes Reinecke
2013-09-20  7:48   ` Ren Mingxin
2013-10-16 19:22   ` James Bottomley
2013-10-17 14:27     ` Ewan Milne
2013-10-23  9:25     ` Hannes Reinecke
2013-10-23  7:46       ` James Bottomley
2013-10-23  9:49         ` Hannes Reinecke
2013-07-01 17:44 ` [PATCHv2 0/7] Limit overall " Jörn Engel
2013-07-01 19:23   ` James Bottomley
2013-07-01 20:55     ` Jörn Engel
2013-07-02  5:48       ` Hannes Reinecke
2013-07-02  6:37       ` James Bottomley
2013-07-02 14:58         ` Jörn Engel [this message]
2013-07-02 16:33           ` James Bottomley
2013-07-02 15:50             ` Jörn Engel
2013-07-10 20:35 ` Ewan Milne
2013-07-12  5:54   ` Ren Mingxin
2013-07-12 13:30     ` Ewan Milne
2013-07-15 10:33       ` Ren Mingxin
2013-07-26  9:52         ` Ren Mingxin
2013-08-07  6:43   ` Ren Mingxin
2013-08-29 13:06     ` Hannes Reinecke
2013-09-24 20:51       ` Ric Wheeler
2013-09-25  5:48         ` Hannes Reinecke
2013-10-02 16:21           ` Hannes Reinecke

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=20130702145809.GA19005@logfs.org \
    --to=joern@logfs.org \
    --cc=bvanassche@acm.org \
    --cc=emilne@redhat.com \
    --cc=hare@suse.de \
    --cc=jbottomley@parallels.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=renmx@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.