public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Jeremy Linton <jlinton@tributary.com>
Cc: Linux Scsi <linux-scsi@vger.kernel.org>,
	"Elliott, Robert (Server Storage)" <Elliott@hp.com>
Subject: Re: [PATCH] Use a more selective error recovery strategy based on device capabilities
Date: Wed, 13 Feb 2013 14:06:07 +0100	[thread overview]
Message-ID: <511B8FBF.9000705@suse.de> (raw)
In-Reply-To: <511A87CA.5010901@tributary.com>

On 02/12/2013 07:19 PM, Jeremy Linton wrote:
> Ideally, Linux should not be sending task management commands to devices that
> don't support the given task mgmt operation.
>
> This patch uses the REPORT SUPPORTED TASK MGMT FUNCTIONS command to enable or
> disable error recovery paths for a given device. For older devices, we make an
> educated guess about what kind of error recovery the device supports. This isn't
> going to be 100% accurate as it should probably take the transport as well as
> the SCSI version into account, but it is a start.
>
> While this patch improves the error recovery paths for modern SCSI networks, the
> error recovery logic continues to fall through to host reset. It also continues
> to send bus and target resets in cases where they may affect working devices. I
> have a partial set of patches which attempt to make intelligent decisions in
> these cases, but they are far more intrusive and at this point not as clear cut.
>
>
> Just in case...
> Signed-off-by: Jeremy Linton <jlinton@tributary.com>

Nice concept.

But unfortunately it failed the reality check; of my zoo of storage 
arrays only NetApp OnTap 8.X and HP P2000 supports the
REPORT SUPPORTED TASK MANAGEMENT FUNCTIONS command.
None of the others (HP EVA, NetApp E-Series, EMC Clariion CX-3) do.

So implementing this command won't buy us much, as it'll default to 
the original behaviour for most cases ...

(Not prejudicing any market share here, of course :-)

Too bad.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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

  parent reply	other threads:[~2013-02-13 13:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 18:19 [PATCH] Use a more selective error recovery strategy based on device capabilities Jeremy Linton
2013-02-12 20:57 ` Elliott, Robert (Server Storage)
2013-02-12 22:00   ` Jeremy Linton
2013-02-13 13:06 ` Hannes Reinecke [this message]
2013-02-13 15:46   ` Jeremy Linton
2013-02-14  2:43     ` Michael Christie
2013-02-14 20:57       ` Jeremy Linton
2013-02-14 23:42         ` Elliott, Robert (Server Storage)
2013-02-15 15:17           ` Jeremy Linton
2013-02-15  7:17         ` 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=511B8FBF.9000705@suse.de \
    --to=hare@suse.de \
    --cc=Elliott@hp.com \
    --cc=jlinton@tributary.com \
    --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