From: Mike Snitzer <snitzer@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: emilne@redhat.com,
device-mapper development <dm-devel@redhat.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
dgilbert@interlog.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: Tue, 24 Sep 2013 08:34:50 -0400 [thread overview]
Message-ID: <20130924123449.GA16083@redhat.com> (raw)
In-Reply-To: <52412581.2010909@suse.de>
On Tue, Sep 24 2013 at 1:39am -0400,
Hannes Reinecke <hare@suse.de> wrote:
> On 09/23/2013 08:18 PM, Ewan Milne wrote:
> > On Fri, 2013-09-20 at 18:03 -0400, Martin K. Petersen wrote:
> > ...
> >> Only a handful of the very latest and greatest devices support RSOC. The
> >> number of devices that support WRITE SAME is orders of magnitude larger.
> >>
> >> Last I checked I had exactly 1 out of about 100 devices in my lab that
> >> supported RSOC.
> > ...
> >> The major headache here of course is that WRITE SAME is inherently
> >> destructive. We can't just fire off one during discovery and see if it
> >> works. For WRITE you can issue a command with a transfer length of 0 to
> >> see if things work. But unfortunately for WRITE SAME a transfer length
> >> of zero means "wipe the entire device". Yikes!
> >>
> >> I guess we could read one sector and try to write it back using WRITE
> >> SAME and a block count of one. But it's really icky. And I don't like
> >> the notion of actually writing things during discovery.
> > ...
> >
> > Just out of curiosity, what do the devices that support WRITE SAME
> > report for the MAXIMUM WRITE SAME LENGTH field in VPD page B0? The
> > spec says that this can be zero if there is no restriction, but is
> > there any chance that most/all of them report some nonzero value?
> >
> > Expanding on Doug's thinking, perhaps there is some combination of
> > VPD page availability / field values that could be used to explicitly
> > enable WRITE SAME? Or, have you been through that already?
> >
> Hehe. Won't do any good.
>
> My drives support 'report opcodes', and report that write same is
> supported:
> ...
> 93 16 Write same(16)
> ...
>
> but no support for page 'b0'. And yes, these are real SAS drives.
Your drive would be fine then since it does support RSOC and specifies
WRITE SAME is supported. Pretty sure Ewan was only suggesting to resort
to looking at the VPD page if RSOC isn't supported.
So are there drives like this?:
1) don't support RSOC
2) do support WRITE SAME
3) do populate VPD page with either WRITE SAME w/ discard bit set or
UNMAP?
next prev parent reply other threads:[~2013-09-24 12:34 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 [this message]
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=20130924123449.GA16083@redhat.com \
--to=snitzer@redhat.com \
--cc=dgilbert@interlog.com \
--cc=dm-devel@redhat.com \
--cc=emilne@redhat.com \
--cc=hare@suse.de \
--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).