linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: dm-devel@redhat.com, linux-scsi@vger.kernel.org
Subject: SCSI's heuristics for enabling WRITE SAME still need work [was: dm mpath: disable WRITE SAME if it fails]
Date: Fri, 20 Sep 2013 17:21:42 -0400	[thread overview]
Message-ID: <20130920212142.GA17898@redhat.com> (raw)
In-Reply-To: <20130919161043.GA27081@redhat.com>

On Thu, Sep 19 2013 at 12:13pm -0400,
Mike Snitzer <snitzer@redhat.com> wrote:

> Workaround the SCSI layer's problematic WRITE SAME heuristics by
> disabling WRITE SAME in the DM multipath device's queue_limits if an
> underlying device disabled it.

...

> This fix doesn't help configurations that have additional devices
> stacked ontop of the mpath device (e.g. LVM created linear DM devices
> ontop).  A proper fix that restacks all the queue_limits from the bottom
> of the device stack up will need to be explored if SCSI will continue to
> use this model of optimistically allowing op codes and then disabling
> them after they fail for the first time.

I really don't think we can afford to keep SCSI's current heuristics for
enabling WRITE SAME, re-stating them for the benefit of others:
1) check if WRITE SAME is supported by sending REPORT SUPPORTED
   OPERATION CODES to the device
2a) if REPORT SUPPORTED OPERATION CODES shows WRITE SAME is supported,
    enable WRITE SAME
2b) if REPORT SUPPORTED OPERATION CODES shows WRITE SAME is not
    supported, disable WRITE SAME
2c) if REPORT SUPPORTED OPERATION CODES isn't supported _and_ the device
    doesn't have an ATA Information VPD page: enable WRITE SAME
    - if/when WRITE SAME does fail, disable it on the failing device

AFAIK the reason for these heuristics is: devices that do support WRITE
SAME cannot properly report as much because they don't support REPORT
SUPPORTED OPERATION CODES -- this lack of RSOC support is apparently
very common?

I can appreciate the idea behind the current heuristics but I think the
prevelence of the other side of the spectrum (SCSI devices that don't
support RSOC or WRITE SAME) was underestimated.  As such we're seeing a
fair amount of WRITE SAME error noise on these systems -- that noise is
itself considered a bug to many.

Also, please see my comment in a related Fedora 19 BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=995271#c23

As I say in that comment:
"A proper fix could be to make SCSI's default be to disable WRITE SAME
for devices that don't properly report they support it.  And possibly
have a whitelist to opt-in to enabling WRITE SAME for select targets."

I'm open to any ideas you might have.

Thanks,
Mike

  reply	other threads:[~2013-09-20 21:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-19 16:13 [PATCH] dm mpath: disable WRITE SAME if it fails Mike Snitzer
2013-09-20 21:21 ` Mike Snitzer [this message]
2013-09-20 22:03   ` SCSI's heuristics for enabling WRITE SAME still need work [was: dm mpath: disable WRITE SAME if it fails] Martin K. Petersen
2013-09-21 15:28     ` Douglas Gilbert
2013-09-23 18:18     ` Ewan Milne
2013-09-24  5:39       ` [dm-devel] " Hannes Reinecke
2013-09-24 12:34         ` Mike Snitzer
2013-09-24 13:49           ` Martin K. Petersen
2013-09-24 15:15             ` Mike Snitzer
2013-09-25 20:52             ` Bernd Schubert
2013-09-25 22:12               ` Douglas Gilbert
2013-09-26  0:44               ` Martin K. Petersen
2013-09-26  5:39                 ` Douglas Gilbert
2013-09-26 13:41                   ` Bernd Schubert
2013-09-26 14:42                     ` Martin K. Petersen
2013-09-26 15:34                       ` Bernd Schubert
2013-09-26 15:47                       ` Douglas Gilbert
2013-09-26 18:42                         ` Saxena, Sumit
2013-09-24 19:12         ` [dm-devel] " Jeremy Linton
2013-09-24 19:37           ` Douglas Gilbert
2013-09-24  9:37     ` Paolo Bonzini
2013-09-24 13:25       ` James Bottomley
2013-09-24 18:39   ` [dm-devel] " Mikulas Patocka
2013-09-24 20:44     ` Martin K. Petersen
2013-09-24 22:02       ` Mike Snitzer

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=20130920212142.GA17898@redhat.com \
    --to=snitzer@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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;
as well as URLs for NNTP newsgroup(s).