From owner-freebsd-hackers@freebsd.org Sat Aug 13 04:44:06 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 5D21DBB80C5 for ; Sat, 13 Aug 2016 04:44:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 292ED19AA for ; Sat, 13 Aug 2016 04:44:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id m101so41617738ioi.2 for ; Fri, 12 Aug 2016 21:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cN6FwlebUsNPzZvzNCtqy50yBgoM0IMeld+GMr2vaII=; b=x7bZCDDq4PLhT8GO0fEL3PVhLfdacaIboefO5kGuFpm8248/8dp1i81k7FUS1/4Kmd CIxGKr/91a+Yi7MY1iBA7PIY01Vyh60fVCFLPS3Exkw+4hmM/akdXZ9nGm9UomZ5zoxO 9ZEY2z7UrH8HeSV43ISkdtNmM33/4n84clu7ErqkzGN7LV7M8NxBPscyphKM0IZz/kkq W15rGyT9oaubcpjGQD+bJyAXfvxltJoo3JF5zvPs26WTmS7INy1iBI8yLNBUrcimE0US aN72ruNnt406C0UYdC1BDvzFnPHsZxYU+7mDR6HqhdsXlCvBGzY7CLB22kla364H9zmo g5aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cN6FwlebUsNPzZvzNCtqy50yBgoM0IMeld+GMr2vaII=; b=ioQaOtFtgdECixcG+BPXn2el/QNXl3Nh+Wv/xhAzpim3t5ARgBFlamcrciycXt6RiG WlnbwOOxZGme4lkddKnJw0Ju2Q19KK4ycUcCYQ4OwhDMya0fNxe05fkIjnWLWwjNKYPp JausmPFfX6KBDCQ/5gz+cgo/fgu5pO7O8h+2O3JQ/P2SKWz/g4RaqkCmoLRcB5Ypmc7r s9Z0ZvPXBRRrEXxQXsY4O/wbApzAmhbQiFlM/3Sza7N7TZchwOAHf/RfZQ1qCMHx3PKy /T06lB0FsLTRl3qAO9TJ71b8/YxA1svRTHgn2pOxNWU2eni71tEExC3RXyHZUCoGW9rk 7wrg== X-Gm-Message-State: AEkoouus90BWwIr7nfOiTd2KtVZpuneex4GAtkxmcV28uuo5fUelwRi9MD/fVFLDe61vA4LwcoSK6GTwlZp+eQ== X-Received: by 10.107.9.39 with SMTP id j39mr21671764ioi.73.1471063445412; Fri, 12 Aug 2016 21:44:05 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.105 with HTTP; Fri, 12 Aug 2016 21:44:04 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <6cec427b-4df1-50f0-3014-a96e5f8210f5@FreeBSD.org> <490347865.SvN7iQoFWI@ralph.baldwin.cx> From: Warner Losh Date: Fri, 12 Aug 2016 22:44:04 -0600 X-Google-Sender-Auth: Q54Ga8gBRA9km1wK5OhEFjvsWis Message-ID: Subject: Re: on BIOS problems with disks larger than 2 TB To: Andriy Gapon Cc: John Baldwin , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Sat, 13 Aug 2016 04:44:06 -0000 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. The lie is different depending on what the underlying disk technology is,which we have no real visibility into in /boot/loader. For MBR, well, it can't go about 2TB anyway for 512 byte sector size and 4k MBRs are (or at least used to be) quite rare. Warner