linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Hannes Reinecke <hare@suse.de>,
	linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/6] libata: Do not retry commands with valid autosense
Date: Mon, 3 Aug 2015 11:55:13 -0400	[thread overview]
Message-ID: <20150803155513.GI32599@mtj.duckdns.org> (raw)
In-Reply-To: <1438616563.2173.16.camel@HansenPartnership.com>

Hello, James.

On Mon, Aug 03, 2015 at 08:42:43AM -0700, James Bottomley wrote:
> I'd think it would be the same reason as all modern transports: it's
> faster and allows processing of sense data in-band.  Under the old
> regime, the device is effectively frozen until you collect the data.
> Under autosense, the data is collected as part of the in-band command
> processing, so it doesn't stall the device.
> 
> Modern drives (and protocols) are moving towards being somewhat more
> chatty with sense data.  It doesn't just signal an error, mostly it's
> just reporting about drive characteristics or other advisory stuff.
> This means that if you handle it the old way, you'll get more drive
> stalls and a corresponding reduction in throughput.

The problem is not the "auto" part but the "sense" part, I guess.  ATA
devices (the harddisks) never reported sense data and instead had a
more rudimentary error bits and for newer devices NCQ log pages, so
libata EH decodes those error information and takes appropriate
actions for the indicated error condition.

Hannes's patchset makes ATA devices mostly bypass libata EH when sense
data is present.  For, say, unrecoverable read errors, it'd be
possible to make this scheme work (broken currently tho); however,
libata and SCSI aren't that closely tied and there currently is no way
for SCSI to tell libata that, e.g., link error was detected on the
device side, so libata will fail to take link recovery actions on
those cases.

This *can* be made to work in a couple different ways but what's
implemented now is pretty broken and making it work properly in any
other way than integrating sense decoding into libata EH would require
major restructuring of the whole thing which I'm not sure would be
worthwhile at this point.

Thanks.

-- 
tejun

  reply	other threads:[~2015-08-03 15:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 13:02 [PATCH 0/6] ZAC host-aware device support Hannes Reinecke
2015-07-31 13:02 ` [PATCH 1/6] libata: Do not retry commands with valid autosense Hannes Reinecke
2015-08-02 15:44   ` Tejun Heo
2015-08-03  7:31     ` Hannes Reinecke
2015-08-03 15:04       ` Tejun Heo
2015-08-03 15:16         ` [PATCH libata/for-4.2-fixes] libata: disable NCQ autosense Tejun Heo
2015-08-03 15:39           ` Tejun Heo
2015-08-03 15:18         ` [PATCH 1/6] libata: Do not retry commands with valid autosense Tejun Heo
2015-08-03 15:42           ` James Bottomley
2015-08-03 15:55             ` Tejun Heo [this message]
2015-08-03 16:44               ` James Bottomley
2015-08-03 16:50                 ` Tejun Heo
2015-08-03 16:47               ` Hannes Reinecke
2015-08-03 17:01                 ` Tejun Heo
2015-08-03 18:21                   ` Hannes Reinecke
2015-07-31 13:02 ` [PATCH 2/6] libata-scsi: use ata_scsi_set_sense when generating ATA sense Hannes Reinecke
2015-07-31 13:02 ` [PATCH 3/6] libata: implement ZBC IN translation Hannes Reinecke
2015-07-31 13:02 ` [PATCH 4/6] libata: Implement ZBC OUT translation Hannes Reinecke
2015-07-31 13:02 ` [PATCH 5/6] libata: support device-managed ZAC devices Hannes Reinecke
2015-07-31 13:02 ` [PATCH 6/6] libata: support host-aware " Hannes Reinecke
2015-08-02 15:47 ` [PATCH 0/6] ZAC host-aware device support Tejun Heo
2015-08-02 16:11 ` James Bottomley
2015-08-03  7:24   ` Hannes Reinecke
2015-08-03 15:31     ` James Bottomley

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=20150803155513.GI32599@mtj.duckdns.org \
    --to=tj@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=hare@suse.de \
    --cc=linux-ide@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).