From: Boaz Harrosh <boaz@plexistor.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
Christoph Hellwig <hch@infradead.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
"Dale R. Worley" <worley@alum.mit.edu>,
linux-scsi@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: Large disk drives
Date: Thu, 06 Nov 2014 16:33:16 +0200 [thread overview]
Message-ID: <545B86AC.3080704@plexistor.com> (raw)
In-Reply-To: <1415269814.29907.19.camel@jarvis.quadriga.com>
On 11/06/2014 12:30 PM, James Bottomley wrote:
> On Wed, 2014-11-05 at 11:30 -0800, Christoph Hellwig wrote:
>> On Wed, Nov 05, 2014 at 11:34:11AM -0500, Alan Stern wrote:
>>>> Sorry, meant to. In principle I'm OK with this as the lever for the
>>>> hack (largely because it means we don't need to do anything) but will
>>>> the distributions support it?
>>>
>>> While I can't speak for the distributions, it's reasonable to assume
>>> that if something becomes part of the upstream kernel then they will
>>> include it.
>>
>> Btw, we do have precedence for looking at partition tables from SCSI
>> code with scsi_partsize(), so the layering violation of looking at
>> EFI labels for disks sizes wouldn't be something entirely new even
>> if we did it in kernel space.
>
> We really don't want to make the decision within the kernel of whether
> we believe the partition size or the disk capacity. For these disk
> problems we need it to be the former, but if we choose that always,
> we'll get weird results on mispartitioned devices.
>
> The usual rule is no policy in the kernel and which to choose is policy,
> so just export the knob (as Alan's patch does) and then let userspace
> decide.
>
I do not think it is a matter of policy.
>From what I understand the situation is that read_capacity_10() which is
32bit, Max 2T byte disks. fails with 0xffffffff and read_capacity_16() (64bit)
is not supported because of wrong scsi-version or because it is blacklisted.
(or device returns not-supported)
Now If sd_read_capacity() succeed then off-course we choose it. What I'm saying
is if read-capacity fails, then should we attempt a new read_capacity_part()?
And sure a user-mode knob if he wants to make policy, like you said, is fine
by me.
But just the simple case of read-capacity failure should we then?
> James
Thanks
Boaz
next prev parent reply other threads:[~2014-11-06 14:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-03 21:06 Large disk drives Dale R. Worley
2014-11-04 7:52 ` James Bottomley
[not found] ` <1415087562.2351.3.camel-7O4RPy5TklLPRNG96csxHf8+0UxHXcjY@public.gmane.org>
2014-11-04 16:14 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1411041112010.966-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2014-11-05 15:51 ` Dale R. Worley
2014-11-05 16:07 ` James Bottomley
2014-11-05 16:34 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1411051130470.1531-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2014-11-05 18:53 ` Boaz Harrosh
2014-11-05 19:30 ` Christoph Hellwig
[not found] ` <20141105193045.GA13265-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2014-11-06 10:30 ` James Bottomley
2014-11-06 14:33 ` Boaz Harrosh [this message]
[not found] ` <545B86AC.3080704-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org>
2014-11-06 15:53 ` Alan Stern
2014-11-06 16:43 ` Boaz Harrosh
[not found] ` <545BA52F.6050205-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-11-06 17:08 ` David Laight
2014-11-06 17:18 ` James Bottomley
2014-11-06 15:54 ` James Bottomley
2014-11-06 16:34 ` Boaz Harrosh
2014-11-06 16:59 ` Alan Stern
2014-11-06 19:23 ` Dale R. Worley
2014-11-06 20:16 ` Alan Stern
2014-11-05 19:15 ` Theodore Ts'o
[not found] ` <20141105191505.GF27083-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2014-11-06 19:17 ` Dale R. Worley
2014-11-05 23:30 ` Dale R. Worley
2014-11-06 17:47 ` Alan Stern
2014-11-07 4:53 Norman Diamond
[not found] ` <533357.25557.qm-303aDswoEIZ5hgrKqgaBcEyFvBl6snHEEwWAM/ix52Y@public.gmane.org>
2014-11-07 10:03 ` David Laight
2014-11-08 0:35 ` Norman Diamond
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=545B86AC.3080704@plexistor.com \
--to=boaz@plexistor.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=worley@alum.mit.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 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.