linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Douglas Gilbert <dgilbert@interlog.com>
To: Bernd Schubert <bernd.schubert@fastmail.fm>,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Mike Snitzer <snitzer@redhat.com>, Hannes Reinecke <hare@suse.de>,
	emilne@redhat.com,
	device-mapper development <dm-devel@redhat.com>,
	linux-scsi@vger.kernel.org
Subject: Re: SCSI's heuristics for enabling WRITE SAME still need work [was: dm mpath: disable WRITE SAME if it fails]
Date: Wed, 25 Sep 2013 18:12:37 -0400	[thread overview]
Message-ID: <52435FD5.6060308@interlog.com> (raw)
In-Reply-To: <52434D0C.1090008@fastmail.fm>

On 13-09-25 04:52 PM, Bernd Schubert wrote:
> On 09/24/2013 03:49 PM, Martin K. Petersen wrote:
>>>>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
>>
>> Mike> So are there drives like this?:
>> Mike> 1) don't support RSOC
>> Mike> 2) do support WRITE SAME
>> Mike> 3) do populate VPD page with either WRITE SAME w/ discard bit set
>> Mike>    or UNMAP?
>>
>> Yes.
>>
>> But again, the fundamental issue here is not the drives. It's the
>> controller firmware. I am not aware of a single SPI/SAS/FC drive that
>> does not support at least WRITE SAME(10).
>>
>> For DIX and T10 PI I have a capabilities mask that each HBA driver fills
>> out that tells the sd driver what the controller can do. And this is
>> combined with whatever the drive reports to figure out whether integrity
>> protection can be enabled.
>>
>> I have been contemplating doing something similar for "fancy" SCSI
>> commands. We could have a flag in the scsi host template that controls
>> whether the device supports WRITE SAME, EXTENDED COPY, etc. The
>> advantage being that we do the matching at discovery time instead of
>> once a WRITE SAME is issued.
>>
>> This would also permit HBA drivers to toggle the feature on a per
>> instance basis. I.e. if "RAID controller firmware rev is lower than XYZ,
>> do not support WRITE SAME".
>>
>> I'll do a PoC later today...
>>
>
> Martin,
>
> I'm afraid we have another problem. I'm currently working on to get
> discard working for our LSI2008 HBAs with attached sata-SSDs and the
> heuristics in sd_read_write_same with based on VPD page 0x89 is not
> correct for this HBA - its SATL supports write-same (although it does
> "Logical block address out of range" at the end of the device, I'm going
> to look into this tomorrow).
>
> So allow LSI SATL or remove this check at all?

LSI implement their SATL in firmware inside their HBAs. Given
their latest firmware release name (*Package_P17_IR_IT_Firmware*
dated 9 August 2013) for their SAS-2 family *** you have 17
versions of that firmware potentially out there in the field.
Updating that firmware is a fiddly process; I use a USB stick
with DOS on it! LSI do fix things in their SATL when flaws are
pointed out.

Generally speaking LSI's SATL is pretty good, at least compared
to another SATL I can think of. They are both moving targets,
and move independently.

Doug Gilbert


*** LSI's SAS-3 HBAs are still at "P1" which I assume is the
     first publically released version.



  reply	other threads:[~2013-09-25 22:13 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 ` SCSI's heuristics for enabling WRITE SAME still need work [was: dm mpath: disable WRITE SAME if it fails] Mike Snitzer
2013-09-20 22:03   ` 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 [this message]
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=52435FD5.6060308@interlog.com \
    --to=dgilbert@interlog.com \
    --cc=bernd.schubert@fastmail.fm \
    --cc=dm-devel@redhat.com \
    --cc=emilne@redhat.com \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=snitzer@redhat.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).