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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
