From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Matthew Wilcox <matthew@wil.cx>,
Linus Torvalds <torvalds@linux-foundation.org>,
Hans de Goede <hdegoede@redhat.com>,
Ben Hutchings <ben@decadent.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>,
Matthew Dharm <mdharm-usb@one-eyed-alien.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag
Date: Wed, 04 Jul 2012 00:07:52 +0400 [thread overview]
Message-ID: <1341346072.3076.6.camel@dabdike> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1207031540410.29825-100000@netrider.rowland.org>
On Tue, 2012-07-03 at 15:50 -0400, Alan Stern wrote:
> On Tue, 3 Jul 2012, Matthew Wilcox wrote:
>
> > On Tue, Jul 03, 2012 at 11:49:00AM -0400, Alan Stern wrote:
> > > On Tue, 3 Jul 2012, James Bottomley wrote:
> > >
> > > > > What happened is that T10
> > > > > in their infinite wisdom decided to put things like "supports TRIM" and
> > > > > "is actually a 4k block size but fakes 512 byte blocks" in the Read
> > > > > Capacity 16 results. So if we want to support those kinds of things
> > > > > (and I think we do), then we need to send Read Capacity 16 to devices.
> > > >
> > > > But anyway, we're stuck ... we have to send RC16 first to support these
> > > > features. We did protest to T10 at the time, but to no avail.
> > >
> > > Does it have to be sent _first_?
> > >
> > > Or would it be okay to send _both_ commands and believe the RC10
> > > capacity rather than the RC16 capacity if they differ?
> >
> > I have no problem with doing that (and believing RC16 over RC10 if RC10
> > claims 0xffffffff, naturally). The problem, as I understand it, is that
> > some devices crash upon receiving RC16 rather than just returning nonsense.
>
> No, that's not the problem we're talking about here. While it is true
> that some devices crash upon receiving RC16, so far we haven't been
> sending RC16 to those devices, so they don't matter for the purposes of
> this discussion.
>
> In fact, usb-storage already has a NO_READ_CAPACITY_16 flag. It was
> introduced because of a card reader that mistakenly attempts to return
> an actual capacity value even when no card is present: It takes the
> number of sectors -- which is 0 -- and subtracts 1 as usual. You can
> imagine what happens next. :-) That's the only device which
> currently has this flag.
>
> The reason for the try_rc_10_first flag is that some devices return
> bogus data in response to RC16. Like, an 800 GB device claiming to
> have 3 exabytes.
So we could easily send both and only believe RC10 if the device is
under 2TB. However, what about all the extra flags we read out of RC16,
like trim, large sector size and DIF capability? If the device lies
about its capacity, won't we get bogus values for those as well, which
is going to cause other screw ups?
James
next prev parent reply other threads:[~2012-07-03 20:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120701172012.078559139@decadent.org.uk>
[not found] ` <4FF14957.3040007@redhat.com>
[not found] ` <CA+55aFyRTXqSvf9m08gbHCB0WhVF14Y6J2-AiFGiuTStq0Jr6Q@mail.gmail.com>
2012-07-02 20:39 ` [ 38/48] SCSI & usb-storage: add try_rc_10_first flag James Bottomley
2012-07-02 22:23 ` Linus Torvalds
2012-07-03 0:41 ` Matthew Wilcox
2012-07-03 6:18 ` James Bottomley
2012-07-03 15:49 ` Alan Stern
2012-07-03 17:32 ` Matthew Wilcox
2012-07-03 19:50 ` Alan Stern
2012-07-03 20:07 ` James Bottomley [this message]
2012-07-03 20:25 ` Alan Stern
2012-07-03 20:35 ` Matthew Wilcox
2012-07-05 21:40 ` Alan Stern
2012-07-06 3:05 ` Matthew Wilcox
2012-07-06 14:00 ` 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=1341346072.3076.6.camel@dabdike \
--to=james.bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ben@decadent.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=mdharm-usb@one-eyed-alien.net \
--cc=stable@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=torvalds@linux-foundation.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