Re: Large disk drives

[Boaz Harrosh <boaz@plexistor.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