Linux SCSI subsystem development
 help / color / mirror / Atom feed
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/

  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