From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 09:04:07 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A17B1065674 for ; Sun, 16 Oct 2011 09:04:07 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id DC3A28FC12 for ; Sun, 16 Oct 2011 09:04:06 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:586a:cd69:8b52:feee]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 87CE74AC1C; Sun, 16 Oct 2011 13:04:05 +0400 (MSD) Date: Sun, 16 Oct 2011 13:03:58 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <165230773.20111016130358@serebryakov.spb.ru> To: Andrei Kolu In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 09:04:07 -0000 Hello, Andrei. You wrote 15 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 20:01:51: > Before that I saw this error message: "gmirror mirror/gm0: corrupt or > invalid GPT data". Solved this problem by starting up system from usb fla= sh > as livecd and recovering gpt. But I still can't boot from geom mirror. GEOM classes (mirror, stripe, raid3, etc) is not compatible with GPT. GPT want to store its copy on last sector(s) of drive. If your put it on gmirror volume, last sector is occuped by gmirror metadata. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 09:29:26 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2BA4106566C for ; Sun, 16 Oct 2011 09:29:26 +0000 (UTC) (envelope-from antinix@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 34BF08FC0A for ; Sun, 16 Oct 2011 09:29:25 +0000 (UTC) Received: by wyi40 with SMTP id 40so1056639wyi.13 for ; Sun, 16 Oct 2011 02:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=VR7xjteXTLLWIaj58zSjvZ3RUr+zxUpVEI7seDBWAQ0=; b=uXg8huhPPAR3AmBwB+x+dNoR2lnaF8Ic1vwaA0h1/22svEmZ/6Y0EmeIaabJa5MpIS Nd+4tiDU+WS4MpqQ6htV7/bo8cv4UZIWUk33Ij27Zl9QOHfwXXieuJw/7yBiYnpdgFaM ZOAII6M9q6B+C32CftNr9jQ2LRJocF9m2LMV0= Received: by 10.216.229.81 with SMTP id g59mr2198847weq.114.1318757365057; Sun, 16 Oct 2011 02:29:25 -0700 (PDT) MIME-Version: 1.0 Sender: antinix@gmail.com Received: by 10.180.79.170 with HTTP; Sun, 16 Oct 2011 02:29:05 -0700 (PDT) In-Reply-To: <165230773.20111016130358@serebryakov.spb.ru> References: <165230773.20111016130358@serebryakov.spb.ru> From: Andrei Kolu Date: Sun, 16 Oct 2011 12:29:05 +0300 X-Google-Sender-Auth: PMZKFhr9D5sIz76OOvJ6zuF_fig Message-ID: To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 09:29:26 -0000 2011/10/16 Lev Serebryakov > Hello, Andrei. > You wrote 15 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2011 =D0=B3., 20:= 01:51: > > > Before that I saw this error message: "gmirror mirror/gm0: corrupt or > > invalid GPT data". Solved this problem by starting up system from usb > flash > > as livecd and recovering gpt. But I still can't boot from geom mirror. > GEOM classes (mirror, stripe, raid3, etc) is not compatible with > GPT. GPT want to store its copy on last sector(s) of drive. If your > put it on gmirror volume, last sector is occuped by gmirror metadata. > > Hi, When I boot from memstick with FreeBSD 9 BETA3 I see error "gptboot: invali= d backup GPT header". So FreeBSD 9 is not compatible with geom mirror anymore because by default installer configure GPT partitions? From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 09:59:42 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1868106564A; Sun, 16 Oct 2011 09:59:42 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id B53948FC12; Sun, 16 Oct 2011 09:59:42 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:586a:cd69:8b52:feee]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 67CC04AC1C; Sun, 16 Oct 2011 13:59:41 +0400 (MSD) Date: Sun, 16 Oct 2011 13:59:34 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1775311702.20111016135934@serebryakov.spb.ru> To: Andrei Kolu In-Reply-To: References: <165230773.20111016130358@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 09:59:43 -0000 Hello, Andrei. You wrote 16 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2011 =D0=B3., 13:29= :05: >> > as livecd and recovering gpt. But I still can't boot from geom mirror. >> GEOM classes (mirror, stripe, raid3, etc) is not compatible with >> GPT. GPT want to store its copy on last sector(s) of drive. If your >> put it on gmirror volume, last sector is occuped by gmirror metadata. > When I boot from memstick with FreeBSD 9 BETA3 I see error "gptboot: inva= lid > backup GPT header". So FreeBSD 9 is not compatible with geom mirror anymo= re > because by default installer configure GPT partitions? Nobody stops you from installing FreeBSD on disk with MBR, even if memstick is prepared with GPT (which have another problem, as images for different memsticks should have different size to have GPT in last sector). And FreeBSD's gptloader has relaxed checks and doesn't refuse to boot if second GPT copy is valid, but not in last sectror(s) of drive. All these questions were discussed a few days ago in current@ mailing list, without any clear conclusion :( Here is proposal (from me and other users), that there should be BIG WARNING in documentation and in utilities when GPT is created not on raw disk, but over some other GEOM. But, again, I didn't see clear approval from "senior developers" (not to speak about Release Engineers) for such change... (I've CCed current@ mailing list, as most of discussion on this topic was there). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 11:23:53 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F3601065672 for ; Sun, 16 Oct 2011 11:23:53 +0000 (UTC) (envelope-from nicolas@i.0x5.de) Received: from n.0x5.de (n.0x5.de [217.197.85.144]) by mx1.freebsd.org (Postfix) with ESMTP id BC49E8FC0C for ; Sun, 16 Oct 2011 11:23:52 +0000 (UTC) Received: by pc5.i.0x5.de (Postfix, from userid 1003) id 748FD1255C2; Sun, 16 Oct 2011 13:05:26 +0200 (CEST) Date: Sun, 16 Oct 2011 13:05:26 +0200 From: Nicolas Rachinsky To: freebsd-geom@freebsd.org Message-ID: <20111016110526.GA1764@mid.pc5.i.0x5.de> Mail-Followup-To: freebsd-geom@freebsd.org References: <165230773.20111016130358@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <165230773.20111016130358@serebryakov.spb.ru> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: 887BAE72 X-PGP-Fingerprint: 039E 9433 115F BC5F F88D 4524 5092 45C4 887B AE72 X-PGP-Keys: http://www.rachinsky.de/nicolas/gpg/nicolas_rachinsky.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 11:23:53 -0000 * Lev Serebryakov [2011-10-16 13:03 +0400]: > GEOM classes (mirror, stripe, raid3, etc) is not compatible with > GPT. GPT want to store its copy on last sector(s) of drive. If your > put it on gmirror volume, last sector is occuped by gmirror metadata. At least with 8.2 there is no problem to put a GPT in a gmirror. There are to warnings during boot (one from the bootloader and one from the kernel) but it's working fine. Of course you have to create the gpt inside the gmirror, not on the same device the gmirror is based on. The warnings occur, when the gpt is seen on the real disk. But later the gpt on the gmirror is used, and on the device created by gmirror, gpt uses the last sector of that device. I hope this will not change. Nicolas -- http://www.rachinsky.de/nicolas From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 11:51:26 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CD351065673 for ; Sun, 16 Oct 2011 11:51:26 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 17EAC8FC15 for ; Sun, 16 Oct 2011 11:51:26 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:586a:cd69:8b52:feee]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 0AC234AC1C; Sun, 16 Oct 2011 15:51:23 +0400 (MSD) Date: Sun, 16 Oct 2011 15:51:17 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1305170562.20111016155117@serebryakov.spb.ru> To: Nicolas Rachinsky In-Reply-To: <20111016110526.GA1764@mid.pc5.i.0x5.de> References: <165230773.20111016130358@serebryakov.spb.ru> <20111016110526.GA1764@mid.pc5.i.0x5.de> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 11:51:26 -0000 Hello, Nicolas. You wrote 16 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 15:05:26: > Of course you have to create the gpt inside the gmirror, not on the > same device the gmirror is based on. The warnings occur, when the gpt > is seen on the real disk. But later the gpt on the gmirror is used, > and on the device created by gmirror, gpt uses the last sector of that > device. > I hope this will not change. Problem is, that new BIOSes could refuse to boot from disk with such misplaced (from raw disk's and BIOS' point of view) secondary GPT. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 14:54:01 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F052106564A; Sun, 16 Oct 2011 14:54:01 +0000 (UTC) (envelope-from luchesar.iliev@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id DDC5D8FC17; Sun, 16 Oct 2011 14:54:00 +0000 (UTC) Received: by eyd10 with SMTP id 10so2890846eyd.13 for ; Sun, 16 Oct 2011 07:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Ob5T8fh1z/PH1kjILNuudMQYwK1wVrsS5z47g3CFeIk=; b=gcXEOxA9O/XUynVEuMYFUwbQVZYQsIGPfJqhOtJPUSzQW42PWtUdO16orkpHuajm+L KagZxCqgjPeQlC+7pltiigaczymTMCEu4rZOAX4H8s4cBVQLTiJwFkzJzgI3kXA+exVy 5zbF4GrO5o9G6su/TJe0ZYsIdU0YueckoYOMI= Received: by 10.223.16.82 with SMTP id n18mr17825589faa.2.1318775111936; Sun, 16 Oct 2011 07:25:11 -0700 (PDT) Received: from [79.124.93.41] ([79.124.93.41]) by mx.google.com with ESMTPS id r16sm17448218fam.8.2011.10.16.07.25.10 (version=SSLv3 cipher=OTHER); Sun, 16 Oct 2011 07:25:10 -0700 (PDT) Message-ID: <4E9AE945.70600@gmail.com> Date: Sun, 16 Oct 2011 17:25:09 +0300 From: "Luchesar V. ILIEV" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: lev@FreeBSD.org, Nicolas Rachinsky , Andrei Kolu References: <165230773.20111016130358@serebryakov.spb.ru> <20111016110526.GA1764@mid.pc5.i.0x5.de> <1305170562.20111016155117@serebryakov.spb.ru> In-Reply-To: <1305170562.20111016155117@serebryakov.spb.ru> X-Enigmail-Version: undefined OpenPGP: id=9A1FEEFF; url=https://cert.acad.bg/pgp-keys/ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-geom@freebsd.org Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 14:54:01 -0000 On 16/10/2011 14:51, Lev Serebryakov wrote: > Hello, Nicolas. > You wrote 16 октября 2011 г., 15:05:26: > >> Of course you have to create the gpt inside the gmirror, not on the >> same device the gmirror is based on. The warnings occur, when the gpt >> is seen on the real disk. But later the gpt on the gmirror is used, >> and on the device created by gmirror, gpt uses the last sector of that >> device. > >> I hope this will not change. > Problem is, that new BIOSes could refuse to boot from disk with such > misplaced (from raw disk's and BIOS' point of view) secondary GPT. > > Probably I'm missing something, but why not do the opposite: configure any gmirrors on top of the GPT partitions? That's at least what I do for my swap volumes, although, admittedly, I'm also heavily using ZFS, which means I don't have many partitions (2 to 3 at most). Cheers, Luchesar -- i.dea.is/luchesar From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 15:31:49 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B231C1065672 for ; Sun, 16 Oct 2011 15:31:49 +0000 (UTC) (envelope-from nicolas@i.0x5.de) Received: from n.0x5.de (n.0x5.de [217.197.85.144]) by mx1.freebsd.org (Postfix) with ESMTP id 540788FC0A for ; Sun, 16 Oct 2011 15:31:48 +0000 (UTC) Received: by pc5.i.0x5.de (Postfix, from userid 1003) id F1C041255B5; Sun, 16 Oct 2011 17:31:47 +0200 (CEST) Date: Sun, 16 Oct 2011 17:31:47 +0200 From: Nicolas Rachinsky To: freebsd-geom@freebsd.org Message-ID: <20111016153147.GA14371@mid.pc5.i.0x5.de> Mail-Followup-To: freebsd-geom@freebsd.org References: <165230773.20111016130358@serebryakov.spb.ru> <20111016110526.GA1764@mid.pc5.i.0x5.de> <1305170562.20111016155117@serebryakov.spb.ru> <4E9AE945.70600@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9AE945.70600@gmail.com> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: 887BAE72 X-PGP-Fingerprint: 039E 9433 115F BC5F F88D 4524 5092 45C4 887B AE72 X-PGP-Keys: http://www.rachinsky.de/nicolas/gpg/nicolas_rachinsky.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 15:31:49 -0000 * "Luchesar V. ILIEV" [2011-10-16 17:25 +0300]: > On 16/10/2011 14:51, Lev Serebryakov wrote: > > Hello, Nicolas. > > You wrote 16 ?????????????? 2011 ??., 15:05:26: > > > >> Of course you have to create the gpt inside the gmirror, not on the > >> same device the gmirror is based on. The warnings occur, when the gpt > >> is seen on the real disk. But later the gpt on the gmirror is used, > >> and on the device created by gmirror, gpt uses the last sector of that > >> device. > > > >> I hope this will not change. > > Problem is, that new BIOSes could refuse to boot from disk with such > > misplaced (from raw disk's and BIOS' point of view) secondary GPT. Such a BIOS is of course possible. But I think that FreeBSD should continue to support such configurations. > Probably I'm missing something, but why not do the opposite: configure > any gmirrors on top of the GPT partitions? That's at least what I do for > my swap volumes, although, admittedly, I'm also heavily using ZFS, which > means I don't have many partitions (2 to 3 at most). If you have to resync after a power failure or a crash, gmirror will start all resyncs at once, which is considerably slower. Sp you have to disable automatic resyncs and handle it differently. And, with onnly one mirror per disc, you cannot get into a situation, where some mirrors use one disk and other mirrors the other one. Nicolas -- http://www.rachinsky.de/nicolas From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 16:17:03 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 3EDAB1065673; Sun, 16 Oct 2011 16:17:03 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 291E514FC5B; Sun, 16 Oct 2011 16:16:58 +0000 (UTC) Message-ID: <4E9B033A.6080103@FreeBSD.org> Date: Sun, 16 Oct 2011 20:15:54 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: lev@FreeBSD.org References: <165230773.20111016130358@serebryakov.spb.ru> <20111016110526.GA1764@mid.pc5.i.0x5.de> <1305170562.20111016155117@serebryakov.spb.ru> In-Reply-To: <1305170562.20111016155117@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 OpenPGP: id=10C8A17A Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5078203A877138781925D8EC" Cc: Nicolas Rachinsky , freebsd-geom@freebsd.org Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 16:17:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5078203A877138781925D8EC Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 16.10.2011 15:51, Lev Serebryakov wrote: > Hello, Nicolas. > You wrote 16 =CF=CB=D4=D1=C2=D2=D1 2011 =C7., 15:05:26: >=20 >> Of course you have to create the gpt inside the gmirror, not on the >> same device the gmirror is based on. The warnings occur, when the gpt >> is seen on the real disk. But later the gpt on the gmirror is used, >> and on the device created by gmirror, gpt uses the last sector of that= >> device. >> I hope this will not change. Yes, it works as you have described. > Problem is, that new BIOSes could refuse to boot from disk with such > misplaced (from raw disk's and BIOS' point of view) secondary GPT. Can you give an example which motherboard does not work? Our boot process uses PMBR and we are not expecting that BIOS has known anything about GPT. So it should work. If BIOS has known about GPT then it is EFI firmware. --=20 WBR, Andrey V. Elsukov --------------enig5078203A877138781925D8EC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOmwNDAAoJEAHF6gQQyKF6atcH/i9E1a25+ocz18zqiW+q2NQc Q/0mDbP57IZpVLo5xhFnRuzPiVnEvHScKSoehg4efPZk12bs7QRDjc2uG/meIUcg yRDGVpKOSuKwQBYSe5MqPbEhQ8kNAgM3wgvTnx+2uHsLSfzNdgm4gzeqjIacyhMR znn+sMHJJsUiey+PPeXJklSh4ibrhRnhDuFAGtSuICIGOdhIC4Ga85C/KSVraI8F G1cKYIH2rMyeHQIQym2qLmYYV2rmdihM+aX79ZF5kkGJc7jKO1UZozzvyTXhyOVi CcLHJeb8plyjgG+a3krU/HGD/KwTjg1S19UbzXZdrB4X/ELzK275w1nmIqLLywA= =BAAi -----END PGP SIGNATURE----- --------------enig5078203A877138781925D8EC-- From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 16:20:33 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79442106566C; Sun, 16 Oct 2011 16:20:33 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 130358FC17; Sun, 16 Oct 2011 16:20:33 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:586a:cd69:8b52:feee]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 4DBBD4AC2D; Sun, 16 Oct 2011 20:20:31 +0400 (MSD) Date: Sun, 16 Oct 2011 20:20:24 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1977197077.20111016202024@serebryakov.spb.ru> To: "Andrey V. Elsukov" In-Reply-To: <4E9B033A.6080103@FreeBSD.org> References: <165230773.20111016130358@serebryakov.spb.ru> <20111016110526.GA1764@mid.pc5.i.0x5.de> <1305170562.20111016155117@serebryakov.spb.ru> <4E9B033A.6080103@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: Nicolas Rachinsky , lev@FreeBSD.org, freebsd-geom@freebsd.org Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 16:20:33 -0000 Hello, Andrey. You wrote 16 =CF=CB=D4=D1=C2=D2=D1 2011 =C7., 20:15:54: >>> Of course you have to create the gpt inside the gmirror, not on the >>> same device the gmirror is based on. The warnings occur, when the gpt >>> is seen on the real disk. But later the gpt on the gmirror is used, >>> and on the device created by gmirror, gpt uses the last sector of that >>> device. >>> I hope this will not change. > Yes, it works as you have described. As we can see, it doesn't work as described for some users. And, again, think about picking up GPT from mirror component, as reported by many others. > Can you give an example which motherboard does not work? No. But any EFI-bases or Hybrid BIOS (with traditional BIOS, but 2Tb+ HDD and GPT support from EFI) could be surprised. > Our boot process uses PMBR and we are not expecting that BIOS has known > anything about GPT. So it should work. If BIOS has known about GPT then > it is EFI firmware. Oh, by "BIOS" I mean any motherboard firmware, of course. BIOS is very generic term, basic input/output system, so EFI firmware is BIOS by definition of "BIOS" term itself, IMHO. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 16:42:39 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id C131D106564A; Sun, 16 Oct 2011 16:42:39 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id AAE43151FDC; Sun, 16 Oct 2011 16:42:34 +0000 (UTC) Message-ID: <4E9B093E.6080008@FreeBSD.org> Date: Sun, 16 Oct 2011 20:41:34 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: lev@FreeBSD.org References: <165230773.20111016130358@serebryakov.spb.ru> <20111016110526.GA1764@mid.pc5.i.0x5.de> <1305170562.20111016155117@serebryakov.spb.ru> <4E9B033A.6080103@FreeBSD.org> <1977197077.20111016202024@serebryakov.spb.ru> In-Reply-To: <1977197077.20111016202024@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 OpenPGP: id=10C8A17A Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig25102448DD5A9B40B520526E" Cc: Nicolas Rachinsky , freebsd-geom@freebsd.org Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 16:42:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig25102448DD5A9B40B520526E Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 16.10.2011 20:20, Lev Serebryakov wrote: >>>> I hope this will not change. >> Yes, it works as you have described. > As we can see, it doesn't work as described for some users. And, > again, think about picking up GPT from mirror component, as reported > by many others. As i see many users complains about their incorrect configurations and misunderstanding of generic things. 1. GPT might work with any GEOM classes and it does work. 2. Yes, you can see some gptboot' and kernel's complains but they are not fatal. Part of they are just because GEOM design. How our booting process works: 1. BIOS calls PMBR. 2. PMBR loads primary GPT and gptboot 3. gptboot/gptzfsboot verifies primary and backup GPT. It can complain about invalid backup header when some GEOM classes had saved metadata in the last sector. But it will work with primary table. 4. The kernel detects GPT on each provider where it can be found. And it will complain that backup GPT header is not in the last LBA for disk providers, but it will detect VALID GPT on gmirror's provider. And it will work with any of them. >> Can you give an example which motherboard does not work? > No. But any EFI-bases or Hybrid BIOS (with traditional BIOS, but > 2Tb+ HDD and GPT support from EFI) could be surprised. Actually, i do not know how you will boot your system without legacy PMBR-way. Our EFI support seems is not finished for the x86/x64. --=20 WBR, Andrey V. Elsukov --------------enig25102448DD5A9B40B520526E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOmwlDAAoJEAHF6gQQyKF6ajcH/A2VuxShCFC86q5/vaECu8Tq nEA/aRFT6yQ3zYjn2q4lPFRmpwBy/AF5bhbv1JCPRy/1fSXKth67TqZIOP9TEtMH TOG2DeCS+o5kK5pDIgbb7u7JSYGtmvleb6t10kZz4oDbe0ZxzRIjg++ozg+yF1ab jFxuFys88u+OD/7P7MIcoEPPsHRqQa5bmQT6ruEDBrMD8iUNsEebTN7RmV367lLp NW+XZ1QyWsry2oS3INtbBsJwbAZ3HPAX1o8+Vn6yDiOzAMIkv/zQdchnsGxRWU7A AfOe15bpr0d6guE1zWLidfejIxfnY445Wj6Jf433m0sVjl/12pFgUQ4kfwCzKo0= =3xDl -----END PGP SIGNATURE----- --------------enig25102448DD5A9B40B520526E-- From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 16:58:56 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A254D1065670 for ; Sun, 16 Oct 2011 16:58:56 +0000 (UTC) (envelope-from nicolas@i.0x5.de) Received: from n.0x5.de (n.0x5.de [217.197.85.144]) by mx1.freebsd.org (Postfix) with ESMTP id 452868FC0C for ; Sun, 16 Oct 2011 16:58:56 +0000 (UTC) Received: by pc5.i.0x5.de (Postfix, from userid 1003) id 2AA961255C2; Sun, 16 Oct 2011 18:58:55 +0200 (CEST) Date: Sun, 16 Oct 2011 18:58:55 +0200 From: Nicolas Rachinsky To: freebsd-geom@freebsd.org Message-ID: <20111016165855.GA96421@mid.pc5.i.0x5.de> Mail-Followup-To: freebsd-geom@freebsd.org References: <165230773.20111016130358@serebryakov.spb.ru> <20111016110526.GA1764@mid.pc5.i.0x5.de> <1305170562.20111016155117@serebryakov.spb.ru> <4E9B033A.6080103@FreeBSD.org> <1977197077.20111016202024@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1977197077.20111016202024@serebryakov.spb.ru> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: 887BAE72 X-PGP-Fingerprint: 039E 9433 115F BC5F F88D 4524 5092 45C4 887B AE72 X-PGP-Keys: http://www.rachinsky.de/nicolas/gpg/nicolas_rachinsky.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: gmirror failed with error 19. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 16:58:56 -0000 * Lev Serebryakov [2011-10-16 20:20 +0400]: > You wrote 16 ??????? 2011 ?., 20:15:54: > > >>> Of course you have to create the gpt inside the gmirror, not on the > >>> same device the gmirror is based on. The warnings occur, when the gpt > >>> is seen on the real disk. But later the gpt on the gmirror is used, > >>> and on the device created by gmirror, gpt uses the last sector of that > >>> device. > >>> I hope this will not change. > > Yes, it works as you have described. > As we can see, it doesn't work as described for some users. And, > again, think about picking up GPT from mirror component, as reported > by many others. Hardcoding the providers should avoid this. Sadly glabel (and gpt and its labels) cannot be hardcoded. At the moment I'm just using the mirror name (with pX... attached) to avoid this. Nicolas -- http://www.rachinsky.de/nicolas From owner-freebsd-geom@FreeBSD.ORG Sun Oct 16 22:50:30 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF28D106566C; Sun, 16 Oct 2011 22:50:30 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A7B608FC12; Sun, 16 Oct 2011 22:50:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9GMoUPl064091; Sun, 16 Oct 2011 22:50:30 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9GMoUWu064080; Sun, 16 Oct 2011 22:50:30 GMT (envelope-from eadler) Date: Sun, 16 Oct 2011 22:50:30 GMT Message-Id: <201110162250.p9GMoUWu064080@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: bin/161677: gpart(8) Probably bug in gptboot X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 22:50:30 -0000 Synopsis: gpart(8) Probably bug in gptboot Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: eadler Responsible-Changed-When: Sun Oct 16 22:50:18 UTC 2011 Responsible-Changed-Why: over to maintainer http://www.freebsd.org/cgi/query-pr.cgi?pr=161677 From owner-freebsd-geom@FreeBSD.ORG Mon Oct 17 00:01:39 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7889A1065673; Mon, 17 Oct 2011 00:01:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 234D08FC14; Mon, 17 Oct 2011 00:01:38 +0000 (UTC) Received: by gyd8 with SMTP id 8so3207680gyd.13 for ; Sun, 16 Oct 2011 17:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=R9uLvsZcXXci/3hYE6XujzCL29sjC+p0NlEO7Z5SN6w=; b=tLQSNiTYvDLVhykzmZi05x7YuXzO9kKyCEtyx873pEiodYMgAQuWDUa7qOJ1+cq1DG 3TkoHMY+t0cSqE5jYY6E9mEca745J01+6LHxe8q6y6b9NmQLOl5bV60hRuHFQXp3apvf wSPTC4TOvMCTpctt3kv9BuMXVmaBfAwQxohIM= Received: by 10.68.15.234 with SMTP id a10mr3463915pbd.10.1318809698127; Sun, 16 Oct 2011 17:01:38 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id h5sm52419616pbq.11.2011.10.16.17.01.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Oct 2011 17:01:37 -0700 (PDT) From: Garrett Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 16 Oct 2011 17:01:34 -0700 Message-Id: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> To: freebsd-geom@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Xin LI Subject: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 00:01:39 -0000 Hi, I was curious why GELI encrypted images produced on 9.0+ = couldn't be loaded on 8.2 images, and it looks like something is broken = with previous versions of FreeBSD (8.2 at least). If I do the following = to generate a disk image on a 9.0+ host: #!/bin/sh set -e dd if=3D/dev/zero bs=3D1m count=3D48 of=3Ddi=20 echo foobar > ckey md=3D$(mdconfig -a -t vnode -f di) geli init -B none -K ckey -P /dev/$md geli attach -k ckey -p /dev/$md makefs -t ffs /dev/$md.eli /usr/src/etc geli detach /dev/$md mdconfig -d -u $md Transfer the image over to an 8.2 host and do the following: #!/bin/sh echo foobar > ckey md=3D$(mdconfig -a -f di) geli attach -k ckey -p /dev/$md The attach will fail with the following message: geli: MD5 hash mismatch for /dev/md0. Please note that according to the documentation for geli init, = unless I was to provide a value via -a (say -a HMAC/MD5), it shouldn't = "Enable data integrity verification". If instead I build the initial = image on FreeBSD 8.2, transfer the image over to a 9.0+ host, then try = to geli attach it as shown above, things just work. Seems like a regression was introduced into geli somewhere in = 9.0.. just haven't started digging in to determine why. Thanks, -Garrett FreeBSD fallout.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226332M: Wed = Oct 12 22:48:55 PDT 2011 = root@fallout.local:/usr/obj/usr/src/sys/FALLOUT amd64 FreeBSD 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC = 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64= From owner-freebsd-geom@FreeBSD.ORG Mon Oct 17 00:54:33 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C32AF106564A for ; Mon, 17 Oct 2011 00:54:33 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 841068FC08 for ; Mon, 17 Oct 2011 00:54:33 +0000 (UTC) Received: by ggeq3 with SMTP id q3so3259459gge.13 for ; Sun, 16 Oct 2011 17:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0Xb3nfPMfkEDTFHd2i/+8gcuOvnUTP8anFfvyVva0jc=; b=FcUgTnjbnqB5cOL2DD2H+kDJs9ybD2urDp+zGQZTpj/MWrLH0pyy/Xjdo2FSMjkkE0 oGRVO8cGAPiCeYSDqZUTPsXmb0P5MZiaH8J9rBVWcGXtV5nURy8Gq92mD2/QbUTRQfTq tnyZaoejltWWuXP3S9chpVGFM1vrKRWREy0X4= MIME-Version: 1.0 Received: by 10.182.225.3 with SMTP id rg3mr974883obc.77.1318811564348; Sun, 16 Oct 2011 17:32:44 -0700 (PDT) Received: by 10.182.188.97 with HTTP; Sun, 16 Oct 2011 17:32:44 -0700 (PDT) In-Reply-To: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> Date: Sun, 16 Oct 2011 17:32:44 -0700 Message-ID: From: Xin LI To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 00:54:33 -0000 On Sun, Oct 16, 2011 at 5:01 PM, Garrett Cooper wrote: [...] > =C2=A0 =C2=A0 =C2=A0 =C2=A0The attach will fail with the following messag= e: > > geli: MD5 hash mismatch for /dev/md0. I'm pretty sure that this is from userland, and because FreeBSD 9.x have support of GELI metadata version 6, while 8.2 have support up to metadata version 5. It's not a regression IMHO. Cheers, --=20 Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-geom@FreeBSD.ORG Mon Oct 17 02:43:17 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83F2D106564A; Mon, 17 Oct 2011 02:43:17 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4CA8FC08; Mon, 17 Oct 2011 02:43:17 +0000 (UTC) Received: by iaky10 with SMTP id y10so6919905iak.13 for ; Sun, 16 Oct 2011 19:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=YpMA5D+TSVZNmJU48hY3ON5JV4xCu23MlIUDrl3FHa0=; b=inLBLAmMMLeHyKnATpnunIoB7bUK+AtzOB7DXFDDevpjsTMKHerScISyL5gc0CKWoG p5sDV7fTOp6rL5TlZwfY2PqKRENWfOHGZ9rrMB5DIfWvs1FdcEeE+n1qHsYvNEozl9i+ 780stSxv1gm8JMNCipYPE8rJJiFzJR1LfMcvc= Received: by 10.42.172.74 with SMTP id m10mr31862963icz.1.1318819396752; Sun, 16 Oct 2011 19:43:16 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id bu33sm32186669ibb.11.2011.10.16.19.43.15 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Oct 2011 19:43:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Sun, 16 Oct 2011 19:43:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> To: Xin LI X-Mailer: Apple Mail (2.1084) Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 02:43:17 -0000 On Oct 16, 2011, at 5:32 PM, Xin LI wrote: > On Sun, Oct 16, 2011 at 5:01 PM, Garrett Cooper = wrote: > [...] >> The attach will fail with the following message: >>=20 >> geli: MD5 hash mismatch for /dev/md0. >=20 > I'm pretty sure that this is from userland, and because FreeBSD 9.x > have support of GELI metadata version 6, while 8.2 have support up to > metadata version 5. It's not a regression IMHO. In other words this is a design flaw, because geli metadata is only = forwards compatible. One of FreeBSD's claims to fame is its backwards = compatibility -- why aren't geom developers adhering to this? Thanks, -Garrett= From owner-freebsd-geom@FreeBSD.ORG Mon Oct 17 02:51:35 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 624A11065670; Mon, 17 Oct 2011 02:51:35 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-yx0-f177.google.com (mail-yx0-f177.google.com [209.85.213.177]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA388FC0C; Mon, 17 Oct 2011 02:51:34 +0000 (UTC) Received: by yxk36 with SMTP id 36so3263599yxk.8 for ; Sun, 16 Oct 2011 19:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=O8IhxJlJ06aKK1RnTC0bz4XetMN1r1sHKtHuQ+EuKJw=; b=Ws/xOKTVyHqkE3dX4aVyhf4sFbyM2lS+s+mqhKpxmBGHrRpC8lEU8iuOReUMXXipnJ mCuOvQPS2hNNq3wCEmkhIGqaLbf5Dg+WGsQAL6BFeKKYhxqYSR9I42K1CU7kYWqWJFkL VrN4+ntY0fjaZN6Sq2kZxHOEoN9JqYNUzHqXE= MIME-Version: 1.0 Received: by 10.182.225.3 with SMTP id rg3mr1117240obc.77.1318819894284; Sun, 16 Oct 2011 19:51:34 -0700 (PDT) Received: by 10.182.188.97 with HTTP; Sun, 16 Oct 2011 19:51:34 -0700 (PDT) In-Reply-To: <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> Date: Sun, 16 Oct 2011 19:51:34 -0700 Message-ID: From: Xin LI To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 02:51:35 -0000 On Sun, Oct 16, 2011 at 7:43 PM, Garrett Cooper wrote: > On Oct 16, 2011, at 5:32 PM, Xin LI wrote: > >> On Sun, Oct 16, 2011 at 5:01 PM, Garrett Cooper wro= te: >> [...] >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0The attach will fail with the following mess= age: >>> >>> geli: MD5 hash mismatch for /dev/md0. >> >> I'm pretty sure that this is from userland, and because FreeBSD 9.x >> have support of GELI metadata version 6, while 8.2 have support up to >> metadata version 5. =C2=A0It's not a regression IMHO. > > In other words this is a design flaw, because geli metadata is only forwa= rds compatible. One of FreeBSD's claims to fame is its backwards compatibil= ity -- why aren't geom developers adhering to this? Backward compatibility is that you can expect what's working in an older version of FreeBSD would just work on a newer version of FreeBSD, not the contrary. Cheers, --=20 Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-geom@FreeBSD.ORG Mon Oct 17 06:36:36 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BADA01065670 for ; Mon, 17 Oct 2011 06:36:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 80EB38FC08 for ; Mon, 17 Oct 2011 06:36:36 +0000 (UTC) Received: by iaky10 with SMTP id y10so7157450iak.13 for ; Sun, 16 Oct 2011 23:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=o5hQpYPoxgP0kWsw9T6USpjW1jPU0sciguoxXvvLmQo=; b=UV1gC9KvEF5cPbjjWgrYE4my0IrMbluwRxHjOxrgHo3mYmq/fcYpfZmGSdw7SAUf9t UVuJWZ7bjgg26C4mp0WQQypNrE5dc1VXKBEaqTaFwdbb1cxk4HXT5GLBhBwiFGKGHYK2 yBD2+8LntkkaLA9k9k3gIVcvyWb96m/sEt4z8= Received: by 10.42.148.198 with SMTP id s6mr36180736icv.56.1318833395936; Sun, 16 Oct 2011 23:36:35 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id n30sm24650720ibl.4.2011.10.16.23.36.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Oct 2011 23:36:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Sun, 16 Oct 2011 23:36:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> To: Xin LI X-Mailer: Apple Mail (2.1084) Cc: freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 06:36:36 -0000 On Oct 16, 2011, at 7:51 PM, Xin LI wrote: > On Sun, Oct 16, 2011 at 7:43 PM, Garrett Cooper = wrote: >> On Oct 16, 2011, at 5:32 PM, Xin LI wrote: >>=20 >>> On Sun, Oct 16, 2011 at 5:01 PM, Garrett Cooper = wrote: >>> [...] >>>> The attach will fail with the following message: >>>>=20 >>>> geli: MD5 hash mismatch for /dev/md0. >>>=20 >>> I'm pretty sure that this is from userland, and because FreeBSD 9.x >>> have support of GELI metadata version 6, while 8.2 have support up = to >>> metadata version 5. It's not a regression IMHO. >>=20 >> In other words this is a design flaw, because geli metadata is only = forwards compatible. One of FreeBSD's claims to fame is its backwards = compatibility -- why aren't geom developers adhering to this? >=20 > Backward compatibility is that you can expect what's working in an > older version of FreeBSD would just work on a newer version of > FreeBSD, not the contrary. Perhaps, but the fact that this behavior / set of expectations = isn't clearly called out in the geli manpage -- and the fact that there = isn't official versioning (or at the very least this isn't made a = requirement based on the output above) associated with each metadata = format is a fault that should be corrected. Otherwise, how can GELI be = considered a viable mechanism for encrypting data across multiple = versions of FreeBSD? It seems very shortsighted that there isn't at = least a mechanism for reading -- or at least rejecting -- later versions = of metadata in an intuitive manner. FWIW if you use geli from an earlier version of FreeBSD (hint: = chroot, jail), it does the right thing.. which means that I have a means = for producing encrypted images on later versions of FreeBSD now. = Nevertheless, having to do so in such a roundabout manner is annoying = and I'm sure I won't be the only one that will be affected by this. Thanks, -Garrett= From owner-freebsd-geom@FreeBSD.ORG Mon Oct 17 08:00:30 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4A6B106566C for ; Mon, 17 Oct 2011 08:00:30 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4D18FC16 for ; Mon, 17 Oct 2011 08:00:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9H80UXV007813 for ; Mon, 17 Oct 2011 08:00:30 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9H80UBd007812; Mon, 17 Oct 2011 08:00:30 GMT (envelope-from gnats) Date: Mon, 17 Oct 2011 08:00:30 GMT Message-Id: <201110170800.p9H80UBd007812@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: bin/161677: gpart(8) Probably bug in gptboot X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 08:00:30 -0000 The following reply was made to PR bin/161677; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, yerenkow@gmail.com Cc: Subject: Re: bin/161677: gpart(8) Probably bug in gptboot Date: Mon, 17 Oct 2011 10:53:45 +0300 This looks like an issue with BIOS emulation in Virtualbox, actually. I think I've already seen some commits that hack our boot code to play better with Virtualbox. Try to build the boot blocks that you use for those images with -DVIRTUALBOX option. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Oct 17 08:30:13 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A2D2106566B for ; Mon, 17 Oct 2011 08:30:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 610098FC0C for ; Mon, 17 Oct 2011 08:30:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9H8UDhp038328 for ; Mon, 17 Oct 2011 08:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9H8UDth038323; Mon, 17 Oct 2011 08:30:13 GMT (envelope-from gnats) Date: Mon, 17 Oct 2011 08:30:13 GMT Message-Id: <201110170830.p9H8UDth038323@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Alexander Yerenkow Cc: Subject: Re: bin/161677: gpart(8) Probably bug in gptboot X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Yerenkow List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 08:30:13 -0000 The following reply was made to PR bin/161677; it has been noted by GNATS. From: Alexander Yerenkow To: Andriy Gapon Cc: bug-followup@freebsd.org Subject: Re: bin/161677: gpart(8) Probably bug in gptboot Date: Mon, 17 Oct 2011 10:59:58 +0300 --001485f62a063e525e04af79fe02 Content-Type: text/plain; charset=ISO-8859-1 2011/10/17 Andriy Gapon > > This looks like an issue with BIOS emulation in Virtualbox, actually. > I think I've already seen some commits that hack our boot code to play > better > with Virtualbox. Try to build the boot blocks that you use for those > images > with -DVIRTUALBOX option. > Don't think so; I got same error if I dd it to USB flash and try to boot on two different laptops. The only workaround I've found yet - is not use amd64 :) > > -- > Andriy Gapon > -- Regards, Alexander Yerenkow --001485f62a063e525e04af79fe02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/10/17 Andriy Gapon <avg@freebsd.org>
=

This looks like an issue with BIOS emulation in Virtualbox, actually.
I think I've already seen some commits that hack our boot code to play = better
with Virtualbox. =A0Try to build the boot blocks that you use for those ima= ges
with -DVIRTUALBOX option.

Don't thi= nk so;
I got same error if I dd it to USB flash and try to boot o= n two different laptops.
The only workaround I've found yet -= is not use amd64 :)
=A0

--
Andriy Gapon



--
Regards,
Alex= ander Yerenkow
--001485f62a063e525e04af79fe02-- From owner-freebsd-geom@FreeBSD.ORG Mon Oct 17 11:07:03 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 366431065675 for ; Mon, 17 Oct 2011 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A8F668FC13 for ; Mon, 17 Oct 2011 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9HB720H099218 for ; Mon, 17 Oct 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9HB725P099216 for freebsd-geom@FreeBSD.org; Mon, 17 Oct 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Oct 2011 11:07:02 GMT Message-Id: <201110171107.p9HB725P099216@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 11:07:03 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/161677 geom gpart(8) Probably bug in gptboot o kern/161486 geom [geli] GELI password entry is too visible o kern/160562 geom [geom][patch] Allow to insert new component to geom_ra o kern/160409 geom [geli] failed to attach provider o kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres o kern/159091 geom [geom] GEOM fails to scan nested partitions to create p kern/158398 geom [headers] [patch] includes o kern/158197 geom [geom] geom_cache with size>1000 leads to panics o kern/157879 geom [libgeom] ABI change without version bump in 8.2 o kern/157863 geom [geli] kbdmux prevents geli passwords from being enter o kern/157739 geom [geom] GPT labels with geom_multipath o kern/157724 geom [geom] gpart(8) 'add' command must preserve gap for sc o kern/157723 geom [geom] GEOM should not process 'c' (raw) partitions fo o kern/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr o kern/154226 geom [geom] GEOM label does not change when you modify them o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/144905 geom [geom][geom_part] panic in gpart_ctlreq when unpluggin o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o bin/131415 geom [geli] keystrokes are unregulary sent to Geli when typ o kern/131353 geom [geom] gjournal(8) kernel lock o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o bin/86388 geom [geom] [geom_part] periodic(8) daily should backup gpa o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. 66 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Oct 17 13:30:28 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A9E0106566B for ; Mon, 17 Oct 2011 13:30:28 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id C8AA18FC0A for ; Mon, 17 Oct 2011 13:30:27 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 174B4BC8; Mon, 17 Oct 2011 15:30:26 +0200 (CEST) Date: Mon, 17 Oct 2011 15:29:45 +0200 From: Pawel Jakub Dawidek To: Garrett Cooper Message-ID: <20111017132945.GG1679@garage.freebsd.pl> References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rWhLK7VZz0iBluhq" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:30:28 -0000 --rWhLK7VZz0iBluhq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 16, 2011 at 11:36:29PM -0700, Garrett Cooper wrote: > On Oct 16, 2011, at 7:51 PM, Xin LI wrote: > > Backward compatibility is that you can expect what's working in an > > older version of FreeBSD would just work on a newer version of > > FreeBSD, not the contrary. >=20 > Perhaps, but the fact that this behavior / set of expectations isn't cle= arly called out in the geli manpage -- and the fact that there isn't offici= al versioning (or at the very least this isn't made a requirement based on = the output above) associated with each metadata format is a fault that shou= ld be corrected. Otherwise, how can GELI be considered a viable mechanism f= or encrypting data across multiple versions of FreeBSD? It seems very short= sighted that there isn't at least a mechanism for reading -- or at least re= jecting -- later versions of metadata in an intuitive manner. > FWIW if you use geli from an earlier version of FreeBSD (hint: chroot, j= ail), it does the right thing.. which means that I have a means for produci= ng encrypted images on later versions of FreeBSD now. Nevertheless, having = to do so in such a roundabout manner is annoying and I'm sure I won't be th= e only one that will be affected by this. Thanks Garrett for your comments. As Xin pointed out, GELI is not forward compatible, but is backwards compatible (GELI device initialized on FreeBSD 8.x will work on 9.x, but this may not be true the other way around). I fully agree that the error should be clear on what exactly is wrong and this should be easy to fix. As for creating forward compatible GELI devices I think the right thing to do here is to: 1. Add '-V version' option for 'geli init' subcommand that will allow to specify metadata version number to use for device initialization. 2. Add 'geli upgrade [-V ] [prov ...]' subcommand that will allow to upgrade the given device to the given metadata version (only to version greater than the current version). If only providers are given, but -V is not given, metadata of the given providers would be upgraded to the latest version support by the system. Would be nice if backup file could be also upgraded. If 'geli upgrade' is executed with no arguments a list of supported metadata versions with some short description and ideally FreeBSD versions that can run the given GELI version will be printed. 3. Print metadata version in 'geli list' output. Would that work for you? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --rWhLK7VZz0iBluhq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6cLckACgkQForvXbEpPzTQpACdEZTLcEsWBFEcm32jT61HcjYx ZpcAoKCHN594pe6KTPEWzS7AXtBfc+2L =VzHS -----END PGP SIGNATURE----- --rWhLK7VZz0iBluhq-- From owner-freebsd-geom@FreeBSD.ORG Mon Oct 17 18:29:25 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38C461065670; Mon, 17 Oct 2011 18:29:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D48278FC0C; Mon, 17 Oct 2011 18:29:24 +0000 (UTC) Received: by qadz30 with SMTP id z30so2996522qad.13 for ; Mon, 17 Oct 2011 11:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8KAmkP4hORSbIX+XXKIxJtRwxS4mi8sCc4IR4k9771Q=; b=MBOQlbiU12TOLJnLKucP6Kuv4e3MuCMDL009+mQrhAoHC2FkDhZ+Is9M2AgfTL3ynW mHGLSy0N3lAQvEJfNbQ8vyFtNspeHwmy53kHZmVHUhMNbOe+C9oZpFqtILYqyWtrcfsf h4dIY0uOFk/0h1S69SN/bnXLq/oS0wUrjSXio= MIME-Version: 1.0 Received: by 10.182.217.33 with SMTP id ov1mr11795751obc.26.1318876163901; Mon, 17 Oct 2011 11:29:23 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Mon, 17 Oct 2011 11:29:23 -0700 (PDT) In-Reply-To: <20111017132945.GG1679@garage.freebsd.pl> References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> <20111017132945.GG1679@garage.freebsd.pl> Date: Mon, 17 Oct 2011 11:29:23 -0700 Message-ID: From: Garrett Cooper To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 18:29:25 -0000 On Mon, Oct 17, 2011 at 6:29 AM, Pawel Jakub Dawidek wrot= e: > On Sun, Oct 16, 2011 at 11:36:29PM -0700, Garrett Cooper wrote: >> On Oct 16, 2011, at 7:51 PM, Xin LI wrote: >> > Backward compatibility is that you can expect what's working in an >> > older version of FreeBSD would just work on a newer version of >> > FreeBSD, not the contrary. >> >> =A0 =A0 =A0 Perhaps, but the fact that this behavior / set of expectatio= ns isn't clearly called out in the geli manpage -- and the fact that there = isn't official versioning (or at the very least this isn't made a requireme= nt based on the output above) associated with each metadata format is a fau= lt that should be corrected. Otherwise, how can GELI be considered a viable= mechanism for encrypting data across multiple versions of FreeBSD? It seem= s very shortsighted that there isn't at least a mechanism for reading -- or= at least rejecting -- later versions of metadata in an intuitive manner. >> =A0 =A0 =A0 FWIW if you use geli from an earlier version of FreeBSD (hin= t: chroot, jail), it does the right thing.. which means that I have a means= for producing encrypted images on later versions of FreeBSD now. Neverthel= ess, having to do so in such a roundabout manner is annoying and I'm sure I= won't be the only one that will be affected by this. > > Thanks Garrett for your comments. > > As Xin pointed out, GELI is not forward compatible, but is backwards > compatible (GELI device initialized on FreeBSD 8.x will work on 9.x, but > this may not be true the other way around). > > I fully agree that the error should be clear on what exactly is wrong > and this should be easy to fix. > > As for creating forward compatible GELI devices I think the right thing > to do here is to: > 1. Add '-V version' option for 'geli init' subcommand that will allow to > =A0 specify metadata version number to use for device initialization. > 2. Add 'geli upgrade [-V ] [prov ...]' subcommand that will > =A0 allow to upgrade the given device to the given metadata version (only > =A0 to version greater than the current version). If only providers are > =A0 given, but -V is not given, metadata of the given providers would be > =A0 upgraded to the latest version support by the system. > =A0 Would be nice if backup file could be also upgraded. > =A0 If 'geli upgrade' is executed with no arguments a list of supported > =A0 metadata versions with some short description and ideally FreeBSD > =A0 versions that can run the given GELI version will be printed. > 3. Print metadata version in 'geli list' output. That suggestion's brilliant. All that we need now is a short blurb in the manpage describing when which metadata was implemented when and I think this will be on the right track. Thanks a bunch! -Garrett From owner-freebsd-geom@FreeBSD.ORG Tue Oct 18 03:27:48 2011 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE3FD1065674; Tue, 18 Oct 2011 03:27:48 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96B4A8FC15; Tue, 18 Oct 2011 03:27:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9I3RmKg023280; Tue, 18 Oct 2011 03:27:48 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9I3RmoB023276; Tue, 18 Oct 2011 03:27:48 GMT (envelope-from eadler) Date: Tue, 18 Oct 2011 03:27:48 GMT Message-Id: <201110180327.p9I3RmoB023276@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/161752: [geom] glabel(8) doesn't get gpt label change X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 03:27:48 -0000 Old Synopsis: GEOM: glabel doesn't get gpt label change New Synopsis: [geom] glabel(8) doesn't get gpt label change Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: eadler Responsible-Changed-When: Tue Oct 18 03:22:41 UTC 2011 Responsible-Changed-Why: assign to maintainer http://www.freebsd.org/cgi/query-pr.cgi?pr=161752 From owner-freebsd-geom@FreeBSD.ORG Tue Oct 18 07:05:01 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 890CC106566B for ; Tue, 18 Oct 2011 07:05:01 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from mail.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 1934F8FC0A for ; Tue, 18 Oct 2011 07:05:00 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by mail.incore.de (Postfix) with ESMTP id E3DB55C879 for ; Tue, 18 Oct 2011 08:48:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from mail.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id xuhuEaDfY1PQ for ; Tue, 18 Oct 2011 08:48:30 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by mail.incore.de (Postfix) with ESMTP id 60BC95C851 for ; Tue, 18 Oct 2011 08:47:52 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id 5A53E450A1 for ; Tue, 18 Oct 2011 08:47:52 +0200 (CEST) Message-ID: <4E9D2117.4090203@dssgmbh.de> Date: Tue, 18 Oct 2011 08:47:51 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <4E69A152.6090408@rdtc.ru> <4E69EB15.50808@rdtc.ru> In-Reply-To: <4E69EB15.50808@rdtc.ru> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: disk partitioning with gmirror + gpt + gjournal (RFC) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 07:05:01 -0000 I am going to use the following paritioning scheme on our servers and programmers' workstations running FreeBSD 8 (system disk): physical drive - geom_mirror - geom_part_gpt - journaled UFS with separate boot and swap partitions. Partition names and sizes are taken from our environment - Your requirements may vary. Main design goal: minimization of data recovery time after unclean shutdown - using software raid-1. Installation steps of a (bootable) system disk (after cleaning): note: = first disk device, = second disk device, gm0= first gmirror, gm1= second gmirror, etc. label the disk # gmirror label -b load -F gm0 # gpart create -s GPT mirror/gm0 create boot partition # gpart add -t freebsd-boot -s 128 mirror/gm0 # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 mirror/gm0 note: if installing from CD/DVD, bootcode is in /dist/boot/pmbr create the swap partition # gpart add -t freebsd-swap -s 4200M mirror/gm0 create the journal partitions # gpart add -t freebsd-swap -s 1G mirror/gm0 # gpart add -t freebsd-swap -s 2G mirror/gm0 # gpart add -t freebsd-swap -s 2G mirror/gm0 # gpart add -t freebsd-swap -s 2G mirror/gm0 create the (journaled) data partitions: root partition # gpart add -t freebsd-ufs -s 1G mirror/gm0 # gjournal label mirror/gm0p7 mirror/gm0p3 note: IMHO journal size doesn't need to exceed data size var partition # gpart add -t freebsd-ufs -s 4G mirror/gm0 # gjournal label mirror/gm0p8 mirror/gm0p4 usr partition # gpart add -t freebsd-ufs -s 16G mirror/gm0 # gjournal label mirror/gm0p9 mirror/gm0p5 home partition (covers remaining disk space) # gpart add -t freebsd-ufs mirror/gm0 # gjournal label mirror/gm0p10 mirror/gm0p6 create the UFS file systems (with labels): # newfs -L fbsdroot -J mirror/gm0p7.journal # newfs -L fbsdvar -J mirror/gm0p8.journal # newfs -L fbsdusr -J mirror/gm0p9.journal # newfs -L fbsdhome -J mirror/gm0p10.journal mirroring the disk: gmirror insert gm0 /etc/fstab could then look like # Device Mountpoint FStype Options Dump Pass# /dev/mirror/gm0p2 none swap sw 0 0 /dev/ufs/fbsdroot / ufs rw,noatime,async 1 1 /dev/ufs/fbsdhome /home ufs rw,noatime,async 2 2 /dev/ufs/fbsdusr /usr ufs rw,noatime,async 2 2 /dev/ufs/fbsdvar /var ufs rw,noatime,async 2 2 ===================================================================== Some questions: Is this disk configuration valid and robust? (I've just started testing) Are there any other proposals - usable as "best known practice", I didn't find a complete setup so far? As the journal size primarily depends on writing speed, needed journal sizes will necessarily grow in the future, because each journal partition must be able to hold all possible changes at a given time interval (10 seconds?). So physical journal size has to be adjusted during migration onto faster hardware (SSD). I would then preferably use just one (suitable) journal partition for multiple data partitions. Could this feature be added to gjournal with an appropiate amount of work? Are there any comments on or additions to these topics? -- Alfred Bartsch Data-Service GmbH From owner-freebsd-geom@FreeBSD.ORG Tue Oct 18 08:19:22 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 686A2106566B for ; Tue, 18 Oct 2011 08:19:22 +0000 (UTC) (envelope-from nicolas@i.0x5.de) Received: from n.0x5.de (n.0x5.de [217.197.85.144]) by mx1.freebsd.org (Postfix) with ESMTP id 11F348FC0A for ; Tue, 18 Oct 2011 08:19:21 +0000 (UTC) Received: by pc5.i.0x5.de (Postfix, from userid 1003) id 4EA5D1255B5; Tue, 18 Oct 2011 10:19:20 +0200 (CEST) Date: Tue, 18 Oct 2011 10:19:20 +0200 From: Nicolas Rachinsky To: freebsd-geom@freebsd.org Message-ID: <20111018081920.GA97840@mid.pc5.i.0x5.de> Mail-Followup-To: freebsd-geom@freebsd.org References: <4E69A152.6090408@rdtc.ru> <4E69EB15.50808@rdtc.ru> <4E9D2117.4090203@dssgmbh.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9D2117.4090203@dssgmbh.de> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: 887BAE72 X-PGP-Fingerprint: 039E 9433 115F BC5F F88D 4524 5092 45C4 887B AE72 X-PGP-Keys: http://www.rachinsky.de/nicolas/gpg/nicolas_rachinsky.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: disk partitioning with gmirror + gpt + gjournal (RFC) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 08:19:22 -0000 * Alfred Bartsch [2011-10-18 08:47 +0200]: > I am going to use the following paritioning scheme on our servers and > programmers' workstations running FreeBSD 8 (system disk): > physical drive - geom_mirror - geom_part_gpt - journaled UFS > with separate boot and swap partitions. [...] > create the UFS file systems (with labels): > # newfs -L fbsdroot -J mirror/gm0p7.journal [...] > # Device Mountpoint FStype Options Dump Pass# > /dev/ufs/fbsdroot / ufs rw,noatime,async 1 1 [...] > Some questions: > Is this disk configuration valid and robust? (I've just started testing) If gmirror kicks one disk, you might end in an unfortunate situation on the next reboot. Since gmirror won't use the kicked disk, gpart will take it an make the partitions available as p#. glabel might use these instead of the labels on gm0p#. Ant then you use the kicked disk. To avoid this, do not use labels but refer to the partitions only as gm0p# (or with the journal as gm0p#.journal). Nicolas -- http://www.rachinsky.de/nicolas From owner-freebsd-geom@FreeBSD.ORG Tue Oct 18 09:41:41 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38622106564A for ; Tue, 18 Oct 2011 09:41:41 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from mail.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id E92608FC0C for ; Tue, 18 Oct 2011 09:41:40 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by mail.incore.de (Postfix) with ESMTP id 4E18D5C8E6 for ; Tue, 18 Oct 2011 11:41:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from mail.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id iFb2scrkQbFq for ; Tue, 18 Oct 2011 11:41:39 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by mail.incore.de (Postfix) with ESMTP id 8444E5C8E3 for ; Tue, 18 Oct 2011 11:41:39 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id 7F18B4509C for ; Tue, 18 Oct 2011 11:41:39 +0200 (CEST) Message-ID: <4E9D49D2.8020801@dssgmbh.de> Date: Tue, 18 Oct 2011 11:41:38 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <4E69A152.6090408@rdtc.ru> <4E69EB15.50808@rdtc.ru> <4E9D2117.4090203@dssgmbh.de> <20111018081920.GA97840@mid.pc5.i.0x5.de> In-Reply-To: <20111018081920.GA97840@mid.pc5.i.0x5.de> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: disk partitioning with gmirror + gpt + gjournal (RFC) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 09:41:41 -0000 Am 18.10.2011 10:19, schrieb Nicolas Rachinsky: > * Alfred Bartsch [2011-10-18 08:47 +0200]: >> I am going to use the following paritioning scheme on our servers >> and programmers' workstations running FreeBSD 8 (system disk): >> physical drive - geom_mirror - geom_part_gpt - journaled UFS with >> separate boot and swap partitions. > [...] >> create the UFS file systems (with labels): # newfs -L fbsdroot -J >> mirror/gm0p7.journal > [...] >> # Device Mountpoint FStype Options Dump >> Pass# /dev/ufs/fbsdroot / ufs rw,noatime,async 1 >> 1 > [...] >> Some questions: Is this disk configuration valid and robust? >> (I've just started testing) > > If gmirror kicks one disk, you might end in an unfortunate > situation on the next reboot. Since gmirror won't use the kicked > disk, gpart will take it an make the partitions available as > p#. glabel might use these instead of the labels on gm0p#. > Ant then you use the kicked disk. > > To avoid this, do not use labels but refer to the partitions only > as gm0p# (or with the journal as gm0p#.journal). Thanks for pointing this out. I'm using filesystem labels (tunefs), no GEOM labels other than gmirror. After executing "gmirror remove gm0 , the partitions on this disk show up as p#, not as mirror/gm0p#, so there is IMHO no ambiguity. If you have experienced problems with gmirror - glabel configurations, I'm interested in more details. -- Alfred Bartsch Data-Service GmbH From owner-freebsd-geom@FreeBSD.ORG Tue Oct 18 10:08:29 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78F19106566C for ; Tue, 18 Oct 2011 10:08:29 +0000 (UTC) (envelope-from nicolas@i.0x5.de) Received: from n.0x5.de (n.0x5.de [217.197.85.144]) by mx1.freebsd.org (Postfix) with ESMTP id 1F72C8FC17 for ; Tue, 18 Oct 2011 10:08:28 +0000 (UTC) Received: by pc5.i.0x5.de (Postfix, from userid 1003) id 01A941255C2; Tue, 18 Oct 2011 12:08:28 +0200 (CEST) Date: Tue, 18 Oct 2011 12:08:27 +0200 From: Nicolas Rachinsky To: freebsd-geom@freebsd.org Message-ID: <20111018100827.GA91400@mid.pc5.i.0x5.de> Mail-Followup-To: freebsd-geom@freebsd.org References: <4E69A152.6090408@rdtc.ru> <4E69EB15.50808@rdtc.ru> <4E9D2117.4090203@dssgmbh.de> <20111018081920.GA97840@mid.pc5.i.0x5.de> <4E9D49D2.8020801@dssgmbh.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9D49D2.8020801@dssgmbh.de> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: 887BAE72 X-PGP-Fingerprint: 039E 9433 115F BC5F F88D 4524 5092 45C4 887B AE72 X-PGP-Keys: http://www.rachinsky.de/nicolas/gpg/nicolas_rachinsky.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: disk partitioning with gmirror + gpt + gjournal (RFC) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 10:08:29 -0000 * Alfred Bartsch [2011-10-18 11:41 +0200]: > Thanks for pointing this out. I'm using filesystem labels (tunefs), no > GEOM labels other than gmirror. ufs labels are handled by glabel. > After executing "gmirror remove gm0 , the partitions on this > disk show up as p#, not as mirror/gm0p#, so there is IMHO no > ambiguity. If you have experienced problems with gmirror - glabel > configurations, I'm interested in more details. But p# contains the same filesystem with the same label as mirror/gm0p#. If glabel sees p# on boot before mirror/gm0p# it may associate ufs/ with p# instead of mirror/gm0p#. This can happen with "glabel label"-labels, ufs-labels and gpt-labels. If you want verbose names, you might be able to use gconcat (with one component) since gconcat can use hardcoded provider names, which should avoid this problem. It would be nice to add the possibility to hardcode providers to glabel. HTH Nicolas -- http://www.rachinsky.de/nicolas From owner-freebsd-geom@FreeBSD.ORG Tue Oct 18 16:21:04 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59B25106564A for ; Tue, 18 Oct 2011 16:21:04 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from mail.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id D0C098FC0A for ; Tue, 18 Oct 2011 16:21:03 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by mail.incore.de (Postfix) with ESMTP id 261425C96A for ; Tue, 18 Oct 2011 18:21:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from mail.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id gGe7nCU8GBun for ; Tue, 18 Oct 2011 18:21:02 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by mail.incore.de (Postfix) with ESMTP id 24CDA5C8C4 for ; Tue, 18 Oct 2011 18:21:02 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id 1D1974509C for ; Tue, 18 Oct 2011 18:21:02 +0200 (CEST) Message-ID: <4E9DA76D.9080605@dssgmbh.de> Date: Tue, 18 Oct 2011 18:21:01 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <4E69A152.6090408@rdtc.ru> <4E69EB15.50808@rdtc.ru> <4E9D2117.4090203@dssgmbh.de> <20111018081920.GA97840@mid.pc5.i.0x5.de> <4E9D49D2.8020801@dssgmbh.de> <20111018100827.GA91400@mid.pc5.i.0x5.de> In-Reply-To: <20111018100827.GA91400@mid.pc5.i.0x5.de> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: disk partitioning with gmirror + gpt + gjournal (RFC) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:21:04 -0000 Am 18.10.2011 12:08, schrieb Nicolas Rachinsky: > * Alfred Bartsch [2011-10-18 11:41 +0200]: >> Thanks for pointing this out. I'm using filesystem labels >> (tunefs), no GEOM labels other than gmirror. > > ufs labels are handled by glabel. > >> After executing "gmirror remove gm0 , the partitions on >> this disk show up as p#, not as mirror/gm0p#, so there is >> IMHO no ambiguity. If you have experienced problems with gmirror >> - glabel configurations, I'm interested in more details. > > But p# contains the same filesystem with the same label as > mirror/gm0p#. If glabel sees p# on boot before mirror/gm0p# > it may associate ufs/ with p# instead of > mirror/gm0p#. > > This can happen with "glabel label"-labels, ufs-labels and > gpt-labels. > Thanks for clarifying this. As I'm looking for a robust configuration, I will refrain from applying any of these labels until a consistent usage will be possible. So with some minor changes the configuration looks like ... create the UFS file systems (without anylabels): # newfs -J mirror/gm0p7.journal # newfs -J mirror/gm0p8.journal # newfs -J mirror/gm0p9.journal # newfs -J mirror/gm0p10.journal ... /etc/fstab could then look like # Device Mountpoint FStype Options Dump Pass# /dev/mirror/gm0p2 none swap sw 0 0 /dev/mirror/gm0p7.journal / ufs rw,noatime,async 1 1 /dev/mirror/gm0p10.journal /home ufs rw,noatime,async 2 2 /dev/mirror/gm0p9.journal /usr ufs rw,noatime,async 2 2 /dev/mirror/gm0p8.journal /var ufs rw,noatime,async 2 2 > > If you want verbose names, you might be able to use gconcat (with > one component) since gconcat can use hardcoded provider names, > which should avoid this problem. > > It would be nice to add the possibility to hardcode providers to > glabel. It's IMHO not the only weakness concerning glabel. Are there any other objections to this method of disk partitioning? -- Alfred Bartsch Data-Service GmbH From owner-freebsd-geom@FreeBSD.ORG Wed Oct 19 13:42:37 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC1B106566B for ; Wed, 19 Oct 2011 13:42:37 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id D33468FC0C for ; Wed, 19 Oct 2011 13:42:36 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 4645928424; Wed, 19 Oct 2011 15:42:35 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6B3C828423; Wed, 19 Oct 2011 15:42:33 +0200 (CEST) Message-ID: <4E9ED3C8.7030607@quip.cz> Date: Wed, 19 Oct 2011 15:42:32 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Alfred Bartsch , freebsd-geom@FreeBSD.org References: <4E69A152.6090408@rdtc.ru> <4E69EB15.50808@rdtc.ru> <4E9D2117.4090203@dssgmbh.de> <4E9D3B56.50300@quip.cz> <4E9D99F3.40104@dssgmbh.de> In-Reply-To: <4E9D99F3.40104@dssgmbh.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: disk partitioning with gmirror + gpt + gjournal (RFC) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 13:42:37 -0000 Alfred Bartsch wrote: > Am 18.10.2011 10:39, schrieb Miroslav Lachman: >> Alfred Bartsch wrote: >>> I am going to use the following paritioning scheme on our servers >>> and programmers' workstations running FreeBSD 8 (system disk): >>> physical drive - geom_mirror - geom_part_gpt - journaled UFS with >>> separate boot and swap partitions. Partition names and sizes are >>> taken from our environment - Your requirements may vary. >> >> It is not good idead to use GPT on top of gmirror as was discussed >> in the near past at freebsd-current@. You can read more in the >> thread "RFC: Project geom-events" In short: >> http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028054.html >> >> > http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028109.html > > I know this thread. But nobody there really mentions which utilities / > BIOSes would fail or destroy the gmirror-metadata. The only > complaining utility I know of is gptboot (only warning during boot). > If You know other applications which will fail due to GPT problems, > please tell me. Most of the problems shown in this thread seem to have > something to do with the combined usage of gpt and glabel, which I'm > avoiding. As is mentioned in the thread, the problem is with any GEOM class storing is metadata at the end of the device (for example gmirror, graid3, glabel and others) > IMHO the only dangerous code is a foreign UEFI, which "repairs" the > last sector of the GPT disk without further inquiry. None of our > machines act in this way up to now. > Once I will get one of those "unfriendly" machines I surely have to > rethink my view of disk partitioning. I expect that this day either > GEOM will be able to handle this situation or ZFS will be > production-ready. UEFI will replace old BIOS sooner or later, so what you will do then? Than you will need to rework your servers and change your setup routine. And I think it is better to avolid known possible problem than hoping "it will not bite me". You can't avoid Murphy's law ;) >> I am using gjournal on few of our servers, but we are slowly >> removing it from our setups. Data writes to gjournaled disks are >> too slow and sometimes gjournal is not playing nice. > > I'm heavily interested in more details. When I did some tests in the past, gjournal cannot be used in combination with iSCSI and I was not able to stop gjournal tasting providers (I was not able to remove / disable gjournal on device) until I stop all of them and unload gjournal kernel module. I don't know the current state. >> Maybe ZFS or UFS+SUJ is better option. > > Yes, maybe. ZFS is mainly for future use. Do you use the second option > on large filesystems? ZFS is there for "a long time". I feel safe to use it in production on few of our servers. I didn't test UFS+SUJ because it is released in forthcoming 9.0 and we are not deploying current on our servers. >>> create the (journaled) data partitions: root partition # gpart >>> add -t freebsd-ufs -s 1G mirror/gm0 # gjournal label mirror/gm0p7 >>> mirror/gm0p3 note: IMHO journal size doesn't need to exceed data >>> size >> >> I don't think gjournal is needed in such small partitions. Classic >> fsck will be fast. >> > You are right. But IMHO I can not mix journaled and not journaled R/W > filesystems on a gmirror or I lose the main advantage of avoiding > remirroring the whole disk after power failure or crash. Yes, you are right, I forgot about this feature. I never used it this way. >>> /etc/fstab could then look like # Device Mountpoint >>> FStype Options Dump Pass# /dev/mirror/gm0p2 none >>> swap sw 0 0 /dev/ufs/fbsdroot / >>> ufs rw,noatime,async 1 1 /dev/ufs/fbsdhome /home >>> ufs rw,noatime,async 2 2 /dev/ufs/fbsdusr /usr >>> ufs rw,noatime,async 2 2 /dev/ufs/fbsdvar /var >>> ufs rw,noatime,async 2 2 >>> ===================================================================== >> >>> >> And there is one more problem which I am mentioning again and again >> - the main problem of labels and gmirror is that "broken" >> (dropped) provider (for example disk ad0) publishes its >> partitioning and labels, so after reboot with degraded mirror, you >> can start the system with /dev/ad0p7 mounted (because it also has >> label "fbsdroot") instead of mirrored one. It depends on order of >> tasting devices etc. and if something didn't change, it is >> unpredictable to me, which device will be choosed if two devices >> have the same label. > > Thanks for clarifying this. As I'm looking for a robust configuration, > I will drop these labels. This leads to some minor changes in my > configuration: > > # newfs -J mirror/gm0p7.journal > # newfs -J mirror/gm0p8.journal > # newfs -J mirror/gm0p9.journal > # newfs -J mirror/gm0p10.journal > > /etc/fstab could then look like > # Device Mountpoint FStype Options Dump Pass# > /dev/mirror/gm0p2 none swap sw 0 0 > /dev/gm0p7.journal / ufs rw,noatime,async 1 1 > /dev/gm0p10.journal /home ufs rw,noatime,async 2 2 > /dev/gm0p9.journal /usr ufs rw,noatime,async 2 2 > /dev/gm0p8.journal /var ufs rw,noatime,async 2 2 > >> >>> Some questions: Is this disk configuration valid and robust? >>> (I've just started testing) Are there any other proposals - >>> usable as "best known practice", I didn't find a complete setup >>> so far? >> >> We are using gmirror with good old mbr / fdisk / bsdlabel without >> mounting by labels and with gjournal only on the big data >> partitions. Not on root, var or partitions with databases (because >> gjournal is slow on writes) > > with fdisk + bsdlabel there are not enough partitions in one slice to > hold all the journals, and as I already mentioned I really want to > minimize recovery time. > With gmirror + gjournal I'm able to activate disk write cache without > losing data consistency, which improves performance significantly. According to following commit message, bsdlabel was extended to 26 partitions 3 years ago. http://lists.freebsd.org/pipermail/cvs-all/2007-December/239719.html (I didn't tested yet, because I don't need it - we are using two slices on our servers) >> I see what you are trying to do and it would be nice if "all works >> as one can expect", but the reality is different. So I don't think >> it is good idea to make it as you described. >> > I'm not yet fully convinced, that my idea of disk partitioning is a > bad one, so please let me take part in your negative experiences with > gjournal. > Thanks in advance. I am not saying that your idea is bad. It just contains some things which I rather avoid. PS: please use Reply All, to post your reply to the mailing list as well From owner-freebsd-geom@FreeBSD.ORG Wed Oct 19 15:30:41 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA5A2106566B; Wed, 19 Oct 2011 15:30:41 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7AC918FC12; Wed, 19 Oct 2011 15:30:41 +0000 (UTC) Received: by vcbfo13 with SMTP id fo13so2477085vcb.13 for ; Wed, 19 Oct 2011 08:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Foi9ybrZbFzJtW+NaHRqyoo0QniO2Nj022bw2y1o/PM=; b=ppEetFK+nVdkaFq5HaI7fmOwszWuDOBWVEVxcQbOz1ScOkt88qRGHxI7WUEuNCveDQ AevpZRl5Nbztw91Nv1wqngRGE4qIBiPxdGa/6Hqcg4DoFUmmT+RCGQsuLn5zQGvaAqi3 a07So0bd1Pfk+usDmXWACA0OIxkU9Sj4drj9I= MIME-Version: 1.0 Received: by 10.182.7.10 with SMTP id f10mr1072108oba.56.1319038240689; Wed, 19 Oct 2011 08:30:40 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Wed, 19 Oct 2011 08:30:39 -0700 (PDT) In-Reply-To: References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> <20111017132945.GG1679@garage.freebsd.pl> Date: Wed, 19 Oct 2011 08:30:39 -0700 Message-ID: From: Garrett Cooper To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:30:42 -0000 On Mon, Oct 17, 2011 at 11:29 AM, Garrett Cooper wrote= : > On Mon, Oct 17, 2011 at 6:29 AM, Pawel Jakub Dawidek wr= ote: >> On Sun, Oct 16, 2011 at 11:36:29PM -0700, Garrett Cooper wrote: >>> On Oct 16, 2011, at 7:51 PM, Xin LI wrote: >>> > Backward compatibility is that you can expect what's working in an >>> > older version of FreeBSD would just work on a newer version of >>> > FreeBSD, not the contrary. >>> >>> =A0 =A0 =A0 Perhaps, but the fact that this behavior / set of expectati= ons isn't clearly called out in the geli manpage -- and the fact that there= isn't official versioning (or at the very least this isn't made a requirem= ent based on the output above) associated with each metadata format is a fa= ult that should be corrected. Otherwise, how can GELI be considered a viabl= e mechanism for encrypting data across multiple versions of FreeBSD? It see= ms very shortsighted that there isn't at least a mechanism for reading -- o= r at least rejecting -- later versions of metadata in an intuitive manner. >>> =A0 =A0 =A0 FWIW if you use geli from an earlier version of FreeBSD (hi= nt: chroot, jail), it does the right thing.. which means that I have a mean= s for producing encrypted images on later versions of FreeBSD now. Neverthe= less, having to do so in such a roundabout manner is annoying and I'm sure = I won't be the only one that will be affected by this. >> >> Thanks Garrett for your comments. >> >> As Xin pointed out, GELI is not forward compatible, but is backwards >> compatible (GELI device initialized on FreeBSD 8.x will work on 9.x, but >> this may not be true the other way around). >> >> I fully agree that the error should be clear on what exactly is wrong >> and this should be easy to fix. >> >> As for creating forward compatible GELI devices I think the right thing >> to do here is to: >> 1. Add '-V version' option for 'geli init' subcommand that will allow to >> =A0 specify metadata version number to use for device initialization. >> 2. Add 'geli upgrade [-V ] [prov ...]' subcommand that will >> =A0 allow to upgrade the given device to the given metadata version (onl= y >> =A0 to version greater than the current version). If only providers are >> =A0 given, but -V is not given, metadata of the given providers would be >> =A0 upgraded to the latest version support by the system. >> =A0 Would be nice if backup file could be also upgraded. >> =A0 If 'geli upgrade' is executed with no arguments a list of supported >> =A0 metadata versions with some short description and ideally FreeBSD >> =A0 versions that can run the given GELI version will be printed. >> 3. Print metadata version in 'geli list' output. > > =A0 =A0That suggestion's brilliant. All that we need now is a short blurb > in the manpage describing when which metadata was implemented when and > I think this will be on the right track. Patch added for the first suggestion here: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161807 . I'll see if I can get around to the other two sometime before the end of the week. Thanks, -Garrett From owner-freebsd-geom@FreeBSD.ORG Wed Oct 19 16:19:19 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6013B106566B for ; Wed, 19 Oct 2011 16:19:19 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 0DAA28FC18 for ; Wed, 19 Oct 2011 16:19:18 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 0F5FF700; Wed, 19 Oct 2011 18:19:15 +0200 (CEST) Date: Wed, 19 Oct 2011 18:18:34 +0200 From: Pawel Jakub Dawidek To: Garrett Cooper Message-ID: <20111019161833.GB1982@garage.freebsd.pl> References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> <20111017132945.GG1679@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:19:19 -0000 --wq9mPyueHGvFACwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 19, 2011 at 08:30:39AM -0700, Garrett Cooper wrote: > Patch added for the first suggestion here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161807 . I'll see if I can > get around to the other two sometime before the end of the week. I'm already working on this. Unfortunately 'upgrade' subcommand will be much harder to implement, because in some cases we would need to rewrite the data for the entire provider. I decided not to add upgrade. It also doesn't buy us much. Even after upgrade you cannot switch to new algorithms or to multi-key encryption, etc. Instead I added 'version' subcommand: geli version [-l] geli version [prov ...] Examples: # geli version kernel: 6 userland: 5 # geli version ada0 gpt/secret ada0: 5 gpt/secret: 3 # geli version -l FreeBSD version: highest supported GELI version: FreeBSD 6.0: 0 FreeBSD 6.1: 0 FreeBSD 6.2: 3 FreeBSD 6.3: 3 FreeBSD 6.4: 3 FreeBSD 7.0: 3 FreeBSD 7.1: 3 FreeBSD 7.2: 3 FreeBSD 7.3: 3 FreeBSD 7.4: 3 FreeBSD 8.0: 3 FreeBSD 8.1: 3 FreeBSD 8.2: 5 FreeBSD 9.0: 6 --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --wq9mPyueHGvFACwf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6e+FgACgkQForvXbEpPzQbAgCg2C/XewpHbiDQ89crCDL2130Q kIwAn3jrv+bUKTreiOfO4sfBY8lG2lK8 =4HhG -----END PGP SIGNATURE----- --wq9mPyueHGvFACwf-- From owner-freebsd-geom@FreeBSD.ORG Wed Oct 19 16:37:35 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B63D1065740; Wed, 19 Oct 2011 16:37:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD7FE8FC17; Wed, 19 Oct 2011 16:37:34 +0000 (UTC) Received: by vcbfo13 with SMTP id fo13so2581776vcb.13 for ; Wed, 19 Oct 2011 09:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+pmuQ6zXwytpYZjcJ9W5UaJjOKFK/fH5C09DlGS3Tko=; b=Xdw7WJ2q5oyplHklC7E6RZvNoy7f0fcTV9s2+BTaqqBBYPr+S0a5rbz1bkw9iOOB3u HIuLzOmfA1thC0qeySm2JGUK7OigrPEY+Z4EV2i1daEXSymlpkmO1F7rF7Q8X9b3OxTx xhuzgbVpfBKgX3EYM62kLLsZtY/2ySzuAR9eM= MIME-Version: 1.0 Received: by 10.182.111.70 with SMTP id ig6mr1118973obb.6.1319042254074; Wed, 19 Oct 2011 09:37:34 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Wed, 19 Oct 2011 09:37:33 -0700 (PDT) In-Reply-To: <20111019161833.GB1982@garage.freebsd.pl> References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> <20111017132945.GG1679@garage.freebsd.pl> <20111019161833.GB1982@garage.freebsd.pl> Date: Wed, 19 Oct 2011 09:37:33 -0700 Message-ID: From: Garrett Cooper To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:37:35 -0000 On Wed, Oct 19, 2011 at 9:18 AM, Pawel Jakub Dawidek wrot= e: > On Wed, Oct 19, 2011 at 08:30:39AM -0700, Garrett Cooper wrote: >> Patch added for the first suggestion here: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161807 . I'll see if I can >> get around to the other two sometime before the end of the week. > > I'm already working on this. Unfortunately 'upgrade' subcommand will be > much harder to implement, because in some cases we would need to rewrite > the data for the entire provider. I decided not to add upgrade. It also > doesn't buy us much. Even after upgrade you cannot switch to new > algorithms or to multi-key encryption, etc. > > Instead I added 'version' subcommand: > > =A0 =A0 =A0 =A0geli version [-l] > =A0 =A0 =A0 =A0geli version [prov ...] > > Examples: > > =A0 =A0 =A0 =A0# geli version > =A0 =A0 =A0 =A0kernel: 6 > =A0 =A0 =A0 =A0userland: 5 > > =A0 =A0 =A0 =A0# geli version ada0 gpt/secret > =A0 =A0 =A0 =A0ada0: 5 > =A0 =A0 =A0 =A0gpt/secret: 3 > > =A0 =A0 =A0 =A0# geli version -l > =A0 =A0 =A0 =A0FreeBSD version: highest supported GELI version: > =A0 =A0 =A0 =A0FreeBSD 6.0: 0 > =A0 =A0 =A0 =A0FreeBSD 6.1: 0 > =A0 =A0 =A0 =A0FreeBSD 6.2: 3 > =A0 =A0 =A0 =A0FreeBSD 6.3: 3 > =A0 =A0 =A0 =A0FreeBSD 6.4: 3 > =A0 =A0 =A0 =A0FreeBSD 7.0: 3 > =A0 =A0 =A0 =A0FreeBSD 7.1: 3 > =A0 =A0 =A0 =A0FreeBSD 7.2: 3 > =A0 =A0 =A0 =A0FreeBSD 7.3: 3 > =A0 =A0 =A0 =A0FreeBSD 7.4: 3 > =A0 =A0 =A0 =A0FreeBSD 8.0: 3 > =A0 =A0 =A0 =A0FreeBSD 8.1: 3 > =A0 =A0 =A0 =A0FreeBSD 8.2: 5 > =A0 =A0 =A0 =A0FreeBSD 9.0: 6 Wouldn't it be better to document this in a manpage like I suggested so the code could be MFCed easier? Also, I like the thought of having a separate subcommand -- version -- for displaying the version output of a geli image. It seems like: geli upgrade md0 should just upgrade md0 to the latest supported metadata format instead of printing out the metadata version, as the implied metadata version should be the latest one by default. Thanks, -Garrett From owner-freebsd-geom@FreeBSD.ORG Wed Oct 19 20:14:05 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A4E8106564A for ; Wed, 19 Oct 2011 20:14:05 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id B45C58FC13 for ; Wed, 19 Oct 2011 20:14:04 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 9CE587D9; Wed, 19 Oct 2011 22:13:59 +0200 (CEST) Date: Wed, 19 Oct 2011 22:13:17 +0200 From: Pawel Jakub Dawidek To: Garrett Cooper Message-ID: <20111019201317.GC1982@garage.freebsd.pl> References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> <20111017132945.GG1679@garage.freebsd.pl> <20111019161833.GB1982@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:14:05 -0000 --oJ71EGRlYNjSvfq7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 19, 2011 at 09:37:33AM -0700, Garrett Cooper wrote: > On Wed, Oct 19, 2011 at 9:18 AM, Pawel Jakub Dawidek wr= ote: > > On Wed, Oct 19, 2011 at 08:30:39AM -0700, Garrett Cooper wrote: > >> Patch added for the first suggestion here: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161807 . I'll see if I can > >> get around to the other two sometime before the end of the week. > > > > I'm already working on this. Unfortunately 'upgrade' subcommand will be > > much harder to implement, because in some cases we would need to rewrite > > the data for the entire provider. I decided not to add upgrade. It also > > doesn't buy us much. Even after upgrade you cannot switch to new > > algorithms or to multi-key encryption, etc. > > > > Instead I added 'version' subcommand: > > > > =A0 =A0 =A0 =A0geli version [-l] > > =A0 =A0 =A0 =A0geli version [prov ...] > > > > Examples: > > > > =A0 =A0 =A0 =A0# geli version > > =A0 =A0 =A0 =A0kernel: 6 > > =A0 =A0 =A0 =A0userland: 5 > > > > =A0 =A0 =A0 =A0# geli version ada0 gpt/secret > > =A0 =A0 =A0 =A0ada0: 5 > > =A0 =A0 =A0 =A0gpt/secret: 3 > > > > =A0 =A0 =A0 =A0# geli version -l > > =A0 =A0 =A0 =A0FreeBSD version: highest supported GELI version: > > =A0 =A0 =A0 =A0FreeBSD 6.0: 0 > > =A0 =A0 =A0 =A0FreeBSD 6.1: 0 > > =A0 =A0 =A0 =A0FreeBSD 6.2: 3 > > =A0 =A0 =A0 =A0FreeBSD 6.3: 3 > > =A0 =A0 =A0 =A0FreeBSD 6.4: 3 > > =A0 =A0 =A0 =A0FreeBSD 7.0: 3 > > =A0 =A0 =A0 =A0FreeBSD 7.1: 3 > > =A0 =A0 =A0 =A0FreeBSD 7.2: 3 > > =A0 =A0 =A0 =A0FreeBSD 7.3: 3 > > =A0 =A0 =A0 =A0FreeBSD 7.4: 3 > > =A0 =A0 =A0 =A0FreeBSD 8.0: 3 > > =A0 =A0 =A0 =A0FreeBSD 8.1: 3 > > =A0 =A0 =A0 =A0FreeBSD 8.2: 5 > > =A0 =A0 =A0 =A0FreeBSD 9.0: 6 >=20 > Wouldn't it be better to document this in a manpage like I suggested > so the code could be MFCed easier? Manual page is in the same place as source code, so it doesn't really matter if we merge geli.8 or geom_eli.c. I was planing to put this into manual page as well, but I think that having it only in the manual page should be enough indeed. > Also, I like the thought of having a separate subcommand -- version -- > for displaying the version output of a geli image. It seems like: >=20 > geli upgrade md0 You meant 'version' here, right? > should just upgrade md0 to the latest supported metadata format > instead of printing out the metadata version, as the implied metadata > version should be the latest one by default. Well, as I said, upgrading is often not possible, as it would require rewrite of all the data, as the code assumes for example that if this is version X, IV should be calculated this way and if it Y some other way, etc. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --oJ71EGRlYNjSvfq7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6fL10ACgkQForvXbEpPzQjhACfXARMnjUlPoOm0VMjNX0pEEJo FnkAoIiV0jFwuJ9yI/9jIV4eZfs0DM9Z =e96d -----END PGP SIGNATURE----- --oJ71EGRlYNjSvfq7-- From owner-freebsd-geom@FreeBSD.ORG Thu Oct 20 09:57:52 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B61041065675 for ; Thu, 20 Oct 2011 09:57:52 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from mail.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 391058FC1A for ; Thu, 20 Oct 2011 09:57:51 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by mail.incore.de (Postfix) with ESMTP id D0CE35CCD8; Thu, 20 Oct 2011 11:57:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from mail.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id lrjfF81LeZYE; Thu, 20 Oct 2011 11:57:49 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by mail.incore.de (Postfix) with ESMTP id 1B2125CC70; Thu, 20 Oct 2011 11:57:49 +0200 (CEST) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id 003004509D; Thu, 20 Oct 2011 11:57:48 +0200 (CEST) Message-ID: <4E9FF09B.4030204@dssgmbh.de> Date: Thu, 20 Oct 2011 11:57:47 +0200 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-geom@freebsd.org References: <4E69A152.6090408@rdtc.ru> <4E69EB15.50808@rdtc.ru> <4E9D2117.4090203@dssgmbh.de> <4E9D3B56.50300@quip.cz> <4E9D99F3.40104@dssgmbh.de> <4E9ED3C8.7030607@quip.cz> In-Reply-To: <4E9ED3C8.7030607@quip.cz> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: disk partitioning with gmirror + gpt + gjournal (RFC) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 09:57:52 -0000 Am 19.10.2011 15:42, schrieb Miroslav Lachman: > Alfred Bartsch wrote: >> Am 18.10.2011 10:39, schrieb Miroslav Lachman: >>> Alfred Bartsch wrote: >>>> I am going to use the following paritioning scheme on our >>>> servers and programmers' workstations running FreeBSD 8 >>>> (system disk): physical drive - geom_mirror - geom_part_gpt - >>>> journaled UFS with separate boot and swap partitions. >>>> Partition names and sizes are taken from our environment - >>>> Your requirements may vary. >>> >>> It is not good idead to use GPT on top of gmirror as was >>> discussed in the near past at freebsd-current@. You can read >>> more in the thread "RFC: Project geom-events" In short: >>> http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028054.html >>> >>> >>> >> >>> http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028109.html >> >> >> I know this thread. But nobody there really mentions which >> utilities / BIOSes would fail or destroy the gmirror-metadata. >> The only complaining utility I know of is gptboot (only warning >> during boot). If You know other applications which will fail due >> to GPT problems, please tell me. Most of the problems shown in >> this thread seem to have something to do with the combined usage >> of gpt and glabel, which I'm avoiding. > > As is mentioned in the thread, the problem is with any GEOM class > storing is metadata at the end of the device (for example gmirror, > graid3, glabel and others) > >> IMHO the only dangerous code is a foreign UEFI, which "repairs" >> the last sector of the GPT disk without further inquiry. None of >> our machines act in this way up to now. Once I will get one of >> those "unfriendly" machines I surely have to rethink my view of >> disk partitioning. I expect that this day either GEOM will be >> able to handle this situation or ZFS will be production-ready. > > UEFI will replace old BIOS sooner or later, so what you will do > then? Than you will need to rework your servers and change your > setup routine. And I think it is better to avolid known possible > problem than hoping "it will not bite me". You can't avoid Murphy's > law ;) > >From my present point of view there are two alternatives: Hardware RAID and (matured) ZFS. If I were a GEOM guru, i would try to enhance the compatibility between upcoming UEFI and GMIRROR / GRAID3 etc. Just guessing: What about adding a flag named "-gpt" "-efi" or just "-offset" to these geoms to reserve enough space (at least 33 sectors) behind the metadata sector at the end of the disk provider to hold whatever secondary gpt table is needed to satisfy UEFI. >>> I am using gjournal on few of our servers, but we are slowly >>> removing it from our setups. Data writes to gjournaled disks >>> are too slow and sometimes gjournal is not playing nice. >> >> I'm heavily interested in more details. > > When I did some tests in the past, gjournal cannot be used in > combination with iSCSI and I was not able to stop gjournal tasting > providers (I was not able to remove / disable gjournal on device) > until I stop all of them and unload gjournal kernel module. I don't > know the current state. Up to now I'm not using any ISCSI equipment. Good to know about some weaknesses in advance. > >>> Maybe ZFS or UFS+SUJ is better option. >> >> Yes, maybe. ZFS is mainly for future use. Do you use the second >> option on large filesystems? > > ZFS is there for "a long time". I feel safe to use it in production > on few of our servers. I didn't test UFS+SUJ because it is released > in forthcoming 9.0 and we are not deploying current on our > servers. > Compared to UFS, ZFS lifetime is relatively short. From my point of view ZFS in its present state is too immature to hold mission critical data, YMMV. On the other hand ZFS needs a lot of redundant disk space and memory to work as expected, not to forget cpu-cycles. IMHO, ZFS is not 32-bit capable, so there is no way to use it on older and small hardware. >>>> create the (journaled) data partitions: root partition # >>>> gpart add -t freebsd-ufs -s 1G mirror/gm0 # gjournal label >>>> mirror/gm0p7 mirror/gm0p3 note: IMHO journal size doesn't >>>> need to exceed data size >>> >>> I don't think gjournal is needed in such small partitions. >>> Classic fsck will be fast. >>> >> You are right. But IMHO I can not mix journaled and not journaled >> R/W filesystems on a gmirror or I lose the main advantage of >> avoiding remirroring the whole disk after power failure or >> crash. > > Yes, you are right, I forgot about this feature. I never used it > this way. > >>>> /etc/fstab could then look like # Device >>>> Mountpoint FStype Options Dump Pass# >>>> /dev/mirror/gm0p2 none swap sw 0 0 >>>> /dev/ufs/fbsdroot / ufs rw,noatime,async 1 1 >>>> /dev/ufs/fbsdhome /home ufs rw,noatime,async 2 2 >>>> /dev/ufs/fbsdusr /usr ufs rw,noatime,async 2 2 >>>> /dev/ufs/fbsdvar /var ufs rw,noatime,async 2 2 >>>> ===================================================================== >>> >>>> >>> >>>> And there is one more problem which I am mentioning again and again >>> - the main problem of labels and gmirror is that "broken" >>> (dropped) provider (for example disk ad0) publishes its >>> partitioning and labels, so after reboot with degraded mirror, >>> you can start the system with /dev/ad0p7 mounted (because it >>> also has label "fbsdroot") instead of mirrored one. It depends >>> on order of tasting devices etc. and if something didn't >>> change, it is unpredictable to me, which device will be choosed >>> if two devices have the same label. >> >> Thanks for clarifying this. As I'm looking for a robust >> configuration, I will drop these labels. This leads to some minor >> changes in my configuration: >> >> # newfs -J mirror/gm0p7.journal # newfs -J mirror/gm0p8.journal # >> newfs -J mirror/gm0p9.journal # newfs -J mirror/gm0p10.journal >> >> /etc/fstab could then look like # Device Mountpoint >> FStype Options Dump Pass# /dev/mirror/gm0p2 none >> swap sw 0 0 /dev/gm0p7.journal / >> ufs rw,noatime,async 1 1 /dev/gm0p10.journal /home >> ufs rw,noatime,async 2 2 /dev/gm0p9.journal /usr >> ufs rw,noatime,async 2 2 /dev/gm0p8.journal /var >> ufs rw,noatime,async 2 2 >> >>> >>>> Some questions: Is this disk configuration valid and robust? >>>> (I've just started testing) Are there any other proposals - >>>> usable as "best known practice", I didn't find a complete >>>> setup so far? >>> >>> We are using gmirror with good old mbr / fdisk / bsdlabel >>> without mounting by labels and with gjournal only on the big >>> data partitions. Not on root, var or partitions with databases >>> (because gjournal is slow on writes) Did you perform any benchmarks (UFS+Softupdates vs. UFS+Gjournal)? If yes, did you compare async mounts + write cache enabled (gjournal) to sync mounts + write cache disabled (softupdates)? If I understand you right, you prefer write speed to data consistency in these cases. This may be the right choice in your environment. >From my point of view, I am happy to find all bits restored in /var after an unclean shutdown for error analysis and recovery purposes, and I hate the vision of having to restore databases from backup, even after power failures. Furthermore I am glad, only having to wait for gmirror synchronizing to regain redundancy after replacing a failed disk. >> >> with fdisk + bsdlabel there are not enough partitions in one >> slice to hold all the journals, and as I already mentioned I >> really want to minimize recovery time. With gmirror + gjournal >> I'm able to activate disk write cache without losing data >> consistency, which improves performance significantly. > > According to following commit message, bsdlabel was extended to 26 > partitions 3 years ago. > http://lists.freebsd.org/pipermail/cvs-all/2007-December/239719.html > > (I didn't tested yet, because I don't need it - we are using two slices > on our servers) I didn't know this, thanks for revealing. I'm not sure if all BSD utilities can deal with this. > >>> I see what you are trying to do and it would be nice if "all >>> works as one can expect", but the reality is different. So I >>> don't think it is good idea to make it as you described. >>> >> I'm not yet fully convinced, that my idea of disk partitioning is >> a bad one, so please let me take part in your negative >> experiences with gjournal. Thanks in advance. > > I am not saying that your idea is bad. It just contains some > things which I rather avoid. To summarize some of the pros and cons of this method of disk partitioning: pros: - IMHO easy to configure - easy to recover from a failed disk (just replace with a suitable one and resync with gmirror, needs no preparation of the new disk) - minimal downtime after unclean shutdowns (gjournal is responsible for this, no sucking fsck on large file systems) - disk write cache can and should be enabled (enhanced performance) - all disk / partition sizes are supported (even > 2TB) - 32 bit version of FreeBSD (i386) is sufficient (small and old hardware remains usable) cons: - danger of overwriting gmirror metadata by an "unfriendly" UEFI-BIOS - to be continued ... Feel free to add some topics here which I am missing. > > PS: please use Reply All, to post your reply to the mailing list as > well PS: Sorry, my bad. As your first reply was only off-list, I believed that you were starting a private conversation. -- Alfred Bartsch Data-Service GmbH From owner-freebsd-geom@FreeBSD.ORG Fri Oct 21 05:02:32 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2A84106564A; Fri, 21 Oct 2011 05:02:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 89CB38FC14; Fri, 21 Oct 2011 05:02:32 +0000 (UTC) Received: by yxn16 with SMTP id 16so4493932yxn.13 for ; Thu, 20 Oct 2011 22:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZDMuhoM2dl4X9j2l2jSiA4qT+tARSi/+HFFqgKFzDlU=; b=mYX6Z3iYeTfL/NKI/GTmitfLewEQc1efHnbFbp+eg6FgIarWXSjSK6JjzPByqYtHsb HSdPAjDcPOdpL7NaWDWyE5rzg8lNccBx+/VonA9SJhzVDpTQcHOZgPzNPKxHSjWxaBzG YtPAvCJOisBWR5lQSXlqWAhSZFLI+O6npsslk= MIME-Version: 1.0 Received: by 10.182.217.33 with SMTP id ov1mr781328obc.26.1319173351684; Thu, 20 Oct 2011 22:02:31 -0700 (PDT) Received: by 10.182.122.33 with HTTP; Thu, 20 Oct 2011 22:02:30 -0700 (PDT) In-Reply-To: <20111019201317.GC1982@garage.freebsd.pl> References: <924643A0-0798-4FAC-8F82-4AFBC56DC8D7@gmail.com> <7EC93C28-6405-443F-92C6-0291F8D88995@gmail.com> <20111017132945.GG1679@garage.freebsd.pl> <20111019161833.GB1982@garage.freebsd.pl> <20111019201317.GC1982@garage.freebsd.pl> Date: Thu, 20 Oct 2011 22:02:30 -0700 Message-ID: From: Garrett Cooper To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Cc: Xin LI , freebsd-geom@freebsd.org Subject: Re: GELI devices produced with 9.0+ fail when mounted on 8.2, etc? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 05:02:33 -0000 On Wed, Oct 19, 2011 at 1:13 PM, Pawel Jakub Dawidek wrote: ... > Manual page is in the same place as source code, so it doesn't really > matter if we merge geli.8 or geom_eli.c. I was planing to put this into > manual page as well, but I think that having it only in the manual page > should be enough indeed. Ok. >> Also, I like the thought of having a separate subcommand -- version -- >> for displaying the version output of a geli image. It seems like: >> >> geli upgrade md0 > > You meant 'version' here, right? Actually, I meant upgrade. Having to explicitly call out the version instead of implying the version that one needs to upgrade to just seems unnecessary / less intuitive. >> should just upgrade md0 to the latest supported metadata format >> instead of printing out the metadata version, as the implied metadata >> version should be the latest one by default. > > Well, as I said, upgrading is often not possible, as it would require > rewrite of all the data, as the code assumes for example that if this is > version X, IV should be calculated this way and if it Y some other way, > etc. Yeah.. and you'll have to build a valid version matrix, and block off certain upgrade paths, etc. Having worked with complicated packaging systems, I understand your concerns :). Thanks! -Garrett