From owner-freebsd-hackers@freebsd.org Mon Aug 15 17:18:55 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EED8BBA31E for ; Mon, 15 Aug 2016 17:18:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5F9C1922; Mon, 15 Aug 2016 17:18:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9171FB98E; Mon, 15 Aug 2016 13:18:53 -0400 (EDT) From: John Baldwin To: Warner Losh Cc: Andriy Gapon , "freebsd-hackers@freebsd.org" Subject: Re: on BIOS problems with disks larger than 2 TB Date: Mon, 15 Aug 2016 10:15:51 -0700 Message-ID: <3259742.YBnQU2zACB@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <6cec427b-4df1-50f0-3014-a96e5f8210f5@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 15 Aug 2016 13:18:53 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 17:18:55 -0000 On Friday, August 12, 2016 10:44:04 PM Warner Losh wrote: > On Fri, Aug 12, 2016 at 2:58 PM, Andriy Gapon wrote: > > On 12/08/2016 22:18, John Baldwin wrote: > >> Hmm, I'm not sure how easy it is to handle this case (i.e. how do you know > >> if an LBA beyond the size is really legit due to truncation vs coming from > >> corrupted metadata). Related is that tsoome's bcache stuff wants to know > >> where the end of the disk is (to avoid reading off the end), so just > >> ignoring the size is not easy. > > > > One idea that I have in mind but haven't really explored yet is for GPT > > formatted disks. Basically, if a GPT label hints that the disk size is larger > > than what BIOS reports, then we could try to read a backup label and if it > > matches what we expect, then we could adjust the size. > > > > Hmm, I think I recall that a long time ago some BIOSes used to do something > > similar with MBR :-) > > I think we should just trust the GPT bounds and ignore the actual size > of the disk. > If this is incorrect, we'll get I/O errors to indicate something is > wrong. Doesn't > matter what's wrong, at the end of the day, and many different > pathologies present > as the same error. We should ignore the total size of the disk reported by BIOS > routines because they lie to stay compatible with the long-dead hand > of the past. Well, we don't always have a GPT for one, and not all BIOS'es lie. We can always just start with what the BIOS says and override it if we find a valid GPT that indicates a larger size (which is what Andriy suggested I believe). -- John Baldwin