From owner-freebsd-bugs@freebsd.org Thu Jan 10 16:16:30 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7254E1490F2F for ; Thu, 10 Jan 2019 16:16:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 09DAC8A70D for ; Thu, 10 Jan 2019 16:16:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C0D361490F2E; Thu, 10 Jan 2019 16:16:29 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF48C1490F2D for ; Thu, 10 Jan 2019 16:16:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ED3C8A70A for ; Thu, 10 Jan 2019 16:16:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 9E7561F64B for ; Thu, 10 Jan 2019 16:16:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x0AGGSGk014275 for ; Thu, 10 Jan 2019 16:16:28 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0AGGSQK014274 for bugs@FreeBSD.org; Thu, 10 Jan 2019 16:16:28 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 234741] Loader fails to load from ZFS with two disks in JBOD configuration Date: Thu, 10 Jan 2019 16:16:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: loader X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tsoome@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 16:16:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234741 --- Comment #12 from Toomas Soome --- (In reply to David Chisnall from comment #11) The problem with disk sizes, BIOS, and kernel is that kernel has its own drivers to read the disk size - whatever type of disk is there, we do have specific drivers and resources in kernel. In loader, we *only* use firmware facilities - for UEFI we have UEFI API, f= or BIOS we have INT13 interface, and unfortunately there is unbelievable amoun= t of bugs, especially if the BIOS is actually emulated on top of UEFI. Especially nasty when the system will hung if you access disk past end. With zfs, we have pool config and uberblock pointer stored in pool labels (= 4), labels are stored 2 in front of the pool and 2 at the back. To read data, we actually should read all 4, find the most recent copy and use it. To read l= ast 2 labels, we need to know the location. In situation where we can not trust the sectors count (if reported at all),= it appeared the only reliable source to get information about size is partit= ion table because it is created by the OS. --=20 You are receiving this mail because: You are the assignee for the bug.=