From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 13:52:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A8C51065672; Wed, 27 Jun 2012 13:52:57 +0000 (UTC) (envelope-from root@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.freebsd.org (Postfix) with ESMTP id E81078FC19; Wed, 27 Jun 2012 13:52:56 +0000 (UTC) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id q5RDDx7R005629; Wed, 27 Jun 2012 09:13:59 -0400 (EDT) Received: (from root@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id q5RDDxTQ005628; Wed, 27 Jun 2012 09:13:59 -0400 (EDT) Received: from mail1.radix.net (mail1.radix.net [207.192.128.31]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id q5QKkb7R024664 for ; Tue, 26 Jun 2012 16:46:37 -0400 (EDT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail1.radix.net (8.13.4/8.13.4) with ESMTP id q5QKkb1r010381 for ; Tue, 26 Jun 2012 16:46:37 -0400 (EDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 638EA2056C2; Tue, 26 Jun 2012 20:43:13 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E23ED106572B; Tue, 26 Jun 2012 20:43:01 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D306106567B; Tue, 26 Jun 2012 20:42:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2C88FC16; Tue, 26 Jun 2012 20:42:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68051B95A; Tue, 26 Jun 2012 16:42:40 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Tue, 26 Jun 2012 13:37:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> In-Reply-To: <4FE9B01C.30306@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206261337.11741.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Jun 2012 16:42:40 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org Status: O X-Status: X-Keywords: X-UID: 32 Cc: freebsd-hackers , Doug Rabson , freebsd-current , Pawel Jakub Dawidek , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 13:52:57 -0000 On Tuesday, June 26, 2012 8:50:36 am Andrey V. Elsukov wrote: > Hi All, > > Some time ago i have started reading the code in the sys/boot. > Especially i'm interested in the partition tables handling. > I found several problems: > 1. There are several copies of the same code in the libi386/biosdisk.c > and common/disk.c, and partially libpc98/biosdisk.c. > 2. ZFS probing is very slow, because the ZFS code doesn't know how many > disks and partitions the system has: > http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 > http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 > 3. The GPT support doesn't check CRC and even doesn't know anything > about the secondary GPT header/table. > > So, i have created the branch and committed the changes: > http://svnweb.freebsd.org/base/user/ae/bootcode/ > The patch is here: > http://people.freebsd.org/~ae/boot.diff > > What i already did: > 1. The partition tables handling now is machine independent, > and it is compatible with the kernel's GEOM_PART implementation. > There is new API for disk drivers in the loader to get information > about partitions and tables: > common/Makefile.inc > common/part.c > common/part.h > > 2. The similar and general code from the disk drivers merged in the > disk.c: > common/disk.c > common/disk.h > i386/libi386/libi386.h > i386/libi386/biosdisk.c > userboot/test/test.c > userboot/userboot/userboot_disk.c > userboot/userboot.h > 3. ZFS code now uses new API and probing on the systems with many disks > should be greatly increased: > zfs/zfs.c > i386/loader/main.c > 4. The gptboot now searches the backup GPT header in the previous sectors, > when it finds the "GEOM::" signature in the last sector. PMBR code also > tries to do the same: > common/gpt.c > i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. > 5. Also the pmbr image now contains one fake partition record. > When several first sectors are damaged the kernel can't detect GPT > (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) > command, but the old pmbr image has an empty partition table and > loader doesn't able to boot from GPT, when there is no partition record > in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' > command, the kernel correctly modifies this partition record. So, this is only > for the first rescue step. As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. > 6. I have changed userboot interface. I guess there is none consumers except > the one test program. But if it isn't that, i can make it compatible. One other consumer is in the bhyve branch. I think the 'kload' patches also use it. However, they can probably be adapted easily. [ Note, I haven't done a detailed review of the patch at all yet. ] -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"