From: Stefan Richter <stefanr-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
To: "Elliott,
Robert (Server Storage)" <Elliott-VXdhtT5mjnY@public.gmane.org>
Cc: "linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"Jason J. Herne"
<hernejj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH] USB enclosures seem to require read(16) with >2TB drives
Date: Sun, 11 Nov 2012 12:17:36 +0100 [thread overview]
Message-ID: <20121111121736.5672b762@stein> (raw)
In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B40294C344C61-NSOR0jG+XgMSZAcGdq5asR6epYMZPwEe5NbjCUgZEJk@public.gmane.org>
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.
> 2. if 16-byte CDBs are supported, then use them; only drop down to 10-byte CDBs if 16-byte CDBs are unavailable. Don't make the decision by comparing the LBA on every IO.
--
Stefan Richter
-=====-===-- =-== -=-==
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-11-11 11:17 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 [this message]
2012-11-12 8:18 ` Stefan Richter
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=20121111121736.5672b762@stein \
--to=stefanr-mtydepgkpcbmyopozt5u/lnah6klmebb@public.gmane.org \
--cc=Elliott-VXdhtT5mjnY@public.gmane.org \
--cc=hernejj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.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).