From: Boaz Harrosh <bharrosh@panasas.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
Grant Grundler <grundler@google.com>,
linux-scsi@vger.kernel.org
Subject: Re: READ CAPACITY 16
Date: Thu, 18 Dec 2008 16:59:11 +0200 [thread overview]
Message-ID: <494A653F.2000403@panasas.com> (raw)
In-Reply-To: <1229611966.4963.41.camel@localhost.localdomain>
James Bottomley wrote:
> On Thu, 2008-12-18 at 16:38 +0200, Boaz Harrosh wrote:
>> OK Then I say D, go to T10, while white list the (0) devices that currently
>> report !SCSI_3 but do support UNMAP. These are only USB right?
>>
>> Your tested devices report SCSI_3? Do all devices that are scsi_level > SCSI_2
>> suppose to support RC16?
>
> The problem isn't whether they support it or not. A proper standards
> compliant SCSI device can be sent READ CAPACITY(16) and just return
> ILLEGAL REQUEST sense quite normally. If those were all the devices in
> the world, we'd send 16 first and fall back to 10.
>
> The problem is that there are devices (USB devices) that go haywire when
> sent a READ CAPACITY 16 command (or, indeed, any other SCSI command not
> in their vocabulary). It's for these devices that we do the 10->16
> dance the way we do in sd.c
>
> Our problem is to identify devices that could reliably receive (and this
> doesn't mean process it just means return a standards compliant response
> without crashing or going out to lunch) READ CAPACITY 16 because the
> current Thin Provisioning draft requires this to indicate thin
> provisioning support.
>
> My take is still that TP devices have to be SCSI-3 SBC-3 or higher, so
> we just check this and for them do READ CAPACITY 16 with fallback to 10
> on ILLEGAL REQUEST return. USB has to whitelist the TP compliant
> devices and not mangle the inquiry version field down to SCSI_2 for them
> and the world will just work.
>
>> My point is make the standard, which is still a draft, crystal clear
>> in a backward compatible way. All new, supporting, devices can be easily
>> identified, and the very few devices that do support the new fixture but
>> were released prior to the finalization of the draft be white-listed.
>> And in any event don't let the standard be broken like that.
>
> James
>
>
OK Jams Mathew thanks that makes sense.
All these emulation layers being in HW, USB, or SW, libata will have to attempt
an higher-then-SCSI_2 if they want RC16 stuff, full stop. That sounds safe to
me, and the market will win.
Boaz
next prev parent reply other threads:[~2008-12-18 14:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-17 16:42 READ CAPACITY 16 Matthew Wilcox
2008-12-17 17:50 ` Grant Grundler
2008-12-17 18:06 ` Matthew Wilcox
2008-12-17 18:57 ` Grant Grundler
2008-12-17 19:04 ` James Bottomley
2008-12-17 19:11 ` Matthew Wilcox
2008-12-17 19:14 ` James Bottomley
2008-12-17 19:32 ` Matthew Wilcox
2008-12-17 19:36 ` James Bottomley
2008-12-17 19:49 ` Matthew Wilcox
2008-12-18 9:05 ` Boaz Harrosh
2008-12-18 14:08 ` Matthew Wilcox
2008-12-18 14:38 ` Boaz Harrosh
2008-12-18 14:49 ` Matthew Wilcox
2008-12-18 14:52 ` James Bottomley
2008-12-18 14:59 ` Boaz Harrosh [this message]
2008-12-18 20:41 ` Douglas Gilbert
-- strict thread matches above, loose matches on Subject: below --
2008-12-17 17:20 bburk
2008-12-17 17:25 ` Matthew Wilcox
2004-12-09 14:33 read capacity 16 Frank Borich
2004-12-09 15:02 ` Christoph Hellwig
2004-12-08 21:07 Frank Borich
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=494A653F.2000403@panasas.com \
--to=bharrosh@panasas.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=grundler@google.com \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.