From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 08:50:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B12E51065670; Sun, 28 Jun 2009 08:50:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206192061.chello.pl [87.206.192.61]) by mx1.freebsd.org (Postfix) with ESMTP id EE5238FC14; Sun, 28 Jun 2009 08:49:59 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DAD9245B36; Sun, 28 Jun 2009 10:49:55 +0200 (CEST) Received: from localhost (chello087206192061.chello.pl [87.206.192.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DA48545683; Sun, 28 Jun 2009 10:49:49 +0200 (CEST) Date: Sun, 28 Jun 2009 10:49:57 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20090628084957.GB4159@garage.freebsd.pl> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-geom@freebsd.org Subject: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 08:50:01 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 27, 2009 at 06:20:49PM -0700, Marcel Moolenaar wrote: > Using the last sector is not only flawed because it creates a race > condition, it's flawed in the assumption that you can always make > a geom part of a mirror by storing meta-data on the geom without > causing corruption. This whole idea of using the last sector was > so that a fully partitioned disk with data could be turned into a > mirrored disk. A neat idea, but hardly the basis for a generic > mirroring implementation when it silently corrupts a disk. This wasn't the idea:) People started putting gmirror on top of partitioned disk, because it was easier/simpler/faster than creating mirror, partitioning and copying the data. I for one never put mirror on already partitioned disk. Although it is sometimes safe to use the last sector. Gjournal already looks for UFS and if UFS is in place, it figures out if the last sector is in use - it isn't if partition size is not multiple of UFS block size. > I think it's better to change gmirror to use the first sector on the > provider. This never creates a race condition and as such, you don't > need to invent a priority scheme, that has it's own set of flaws on > top of it. The only downside is that it's not easy to make a fully > partitioned and populated disk part of a mirror: one would need to > move the data forward one sector to free the first sector. This we > can actually do by inserting a GEOM that does it while I/O is still > ongoing. The good thing is: we need a class that does exactly this > for implementing the "move" verb in gpart. There were two reasons to use the last sector instead of first: 1. You want to be able to boot from gmirror. If all your data will be moved forward your boot sectors and kernel will be harder to find. 2. For recovery reasons you may want to turn off gmirror and still be able to access your data. Note that gmirror can handle the case where disk, slice and partition share the same last sector - it simply stores provider size in its metadata, so once it gets disk for tasting it detects its too big and ignores it, then slice will be given for tasting, but it also has larger size than expected and will be ignored as well. Finally partition will be tasted and gmirror configured. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKRy61ForvXbEpPzQRAmOAAJ44Mp928wYkoBPD3p64vr3tA0aW9gCcDqWO Dr4QaHHEB5I33pAqDmt6CWQ= =6fRJ -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND--