From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: "Elliott, Robert (Server Storage)" <Elliott@hp.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"Jason J. Herne" <hernejj@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [PATCH] USB enclosures seem to require read(16) with >2TB drives
Date: Mon, 12 Nov 2012 09:18:14 +0100 [thread overview]
Message-ID: <20121112091814.198f0a62@stein> (raw)
In-Reply-To: <20121111121736.5672b762@stein>
On Nov 11 Stefan Richter wrote:
> On Nov 09 Elliott, Robert (Server Storage) wrote:
> > I recommend broadening this patch. T10 is discussing making READ (10), WRITE (10), etc. obsolete in SBC-4 in favor of their 16-byte CDB counterparts.
> >
> > The algorithm should be:
> > 1. During discovery, determine if 16-byte CDBs are supported. There are several ways to determine this:
> > a) REPORT SUPPORTED OPERATION CODES command succeeds and reports that READ (16) et al are supported.
> > b) READ (16) command specifying a Transfer Length of zero succeeds.
> > c) READ CAPACITY (16) command succeeds and reports that the capacity is > 2 TiB.
> > d) (future) INQUIRY command succeeds fetching the Block Device Characteristics VPD page and notices a new field added by the SBC-4 simplified SCSI feature set proposal.
> >
> > Since REPORT SUPPORTED OPERATION CODES is optional, it won't always work. READ CAPACITY (16) used to be optional for < 2 TiB drives, so it won't always work either. READ (16) will always work, but requires the drive to be spun up beforehand (e.g., with START STOP UNIT).
>
> This won't work. It will crash badly written device firmwares.
>
> Instead, try the (10) commands on the SBC-4 device and let it respond that
> it does not implement these commands. Or have other means to be certain of
> SBC-4 compliance without issuing commands that were optional in or not
> defined by earlier revisions of the spec. I wonder whether testing for
> INQUIRY_data.VERSION >= something is a sufficiently safe test.
Let me revise this: Try READ CAPACITY (10) first (unless SPC-3's
INQUIRY_data.PROTECT is set, in which case I don't know what is safer;
READ CAPACITY (16) first or READ CAPACITY (10) first).
If this showed a capacity > 2 TB, then Jason's suggestion to always only
issue READ (16) to all USB attached devices makes a lot of sense to me if
it is true that Windows 7 never issues READ (10) to them.
That would be what the proposed patch does. What about WRITE and the
various other (10)/(16) pairs of commands though?
I don't know what's best in case of transports other than USB (after
capacity > 2 TB was established).
--
Stefan Richter
-=====-===-- =-== -==--
http://arcgraph.de/sr/
next prev parent reply other threads:[~2012-11-12 8:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-09 16:08 [PATCH] USB enclosures seem to require read(16) with >2TB drives Jason J. Herne
2012-11-09 16:33 ` Elliott, Robert (Server Storage)
[not found] ` <94D0CD8314A33A4D9D801C0FE68B40294C344C61-NSOR0jG+XgMSZAcGdq5asR6epYMZPwEe5NbjCUgZEJk@public.gmane.org>
2012-11-11 11:17 ` Stefan Richter
2012-11-12 8:18 ` Stefan Richter [this message]
2012-11-12 11:17 ` James Bottomley
2012-11-12 11:33 ` James Bottomley
[not found] ` <1352719990.2449.23.camel-sFMDBYUN5F8GjUHQrlYNx2Wm91YjaHnnhRte9Li2A+AAvxtiuMwx3w@public.gmane.org>
2012-11-12 14:31 ` Paolo Bonzini
[not found] ` <50A10856.6090009-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-11-12 15:01 ` Jason J. Herne
2012-11-12 15:28 ` James Bottomley
2012-11-12 15:10 ` James Bottomley
2012-11-12 15:22 ` Jason J. Herne
2012-11-12 15:35 ` Paolo Bonzini
[not found] ` <50A1173D.8090603-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-11-12 16:06 ` Alan Stern
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=20121112091814.198f0a62@stein \
--to=stefanr@s5r6.in-berlin.de \
--cc=Elliott@hp.com \
--cc=hernejj@gmail.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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