From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: Large disk drives Date: Thu, 06 Nov 2014 16:33:16 +0200 Message-ID: <545B86AC.3080704@plexistor.com> References: <1415203668.13212.2.camel@jarvis> <20141105193045.GA13265@infradead.org> <1415269814.29907.19.camel@jarvis.quadriga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f46.google.com ([74.125.82.46]:33797 "EHLO mail-wg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751751AbaKFOdU (ORCPT ); Thu, 6 Nov 2014 09:33:20 -0500 Received: by mail-wg0-f46.google.com with SMTP id x13so1337597wgg.33 for ; Thu, 06 Nov 2014 06:33:19 -0800 (PST) In-Reply-To: <1415269814.29907.19.camel@jarvis.quadriga.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: James Bottomley , Christoph Hellwig Cc: Alan Stern , "Dale R. Worley" , linux-scsi@vger.kernel.org, linux-usb@vger.kernel.org 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