From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 05:34:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 927EE5E2 for ; Fri, 25 Jul 2014 05:34:59 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 394F323C0 for ; Fri, 25 Jul 2014 05:34:59 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s6P5Yvg0053727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Jul 2014 23:34:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s6P5Yvd0053724; Thu, 24 Jul 2014 23:34:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 24 Jul 2014 23:34:57 -0600 (MDT) From: Warren Block To: Dave Hayes Subject: Re: Gmirror + gpart corruption on 9.3-PRE In-Reply-To: <53D1DD47.4040403@jetcafe.org> Message-ID: References: <53D1BDB2.7030906@jetcafe.org> <53D1DD47.4040403@jetcafe.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 24 Jul 2014 23:34:57 -0600 (MDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 05:34:59 -0000 On Thu, 24 Jul 2014, Dave Hayes wrote: > On 07/24/2014 21:04, Warren Block wrote: >> I believe that GPT tables somehow work only on the drive level. That >> is, the GPT partitioning created inside the mirror actually overwrites >> the existing one on the drive. As odd as it sounds, I think this is >> intentional: GPT tables are only supposed to be at the beginning and end >> of a physical drive. But I'm also not the one to explain it. >> >> However, the attempted GPT partitioning inside the mirrors is not needed >> and can be left out. > > I did this because newfs seemed to corrupt the partition table if I did not > do this. Following the procedure in my GPT partition link, I did not have that problem. The old Handbook procedure for creating mirrors did some questionable things which could have caused problems. The new (current) one does it right. >> GPT tests got more strict at some point. Maybe the rules for GPT tables >> did also. > > That sounds like the simplest explanation. > >> For reference, here is my article on mirroring GPT disk partitions. I >> do not recommend it. (Consider the head contention when multiple >> mirrors on the same drive attempt to rebuild. Or disable automatic >> rebuilding, but then it's going to be unpleasant in an emergency.) > > Since I'm only having two mirrors, would it be better to disable just the > automatic rebuilding on the swap space? I think that would be ideal. Swap doesn't need to be rebuilt anyway, the mirror could just be destroyed and recreated. > Would graid be better to use to achieve a mirrored volume? Seems unlikely to me. The main advantage graid(8) has is the BIOS being able to boot from the mirror directly. >> For drives under 2TB, use MBR and bsdlabels, as ugly as it is. The >> recently-rewritten Handbook procedure shows the right way to do it, >> including alignment: >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html > > Yeah, I'd do this except there will come a day when 2TB drives cannot be > found, and I have a significant history of having machines more than 6-7 > years old. True. But partitioning can be specific to the drive. It's not like GPT-partitioned drives can be copied with dd (well, not correctly). A new drive would be partitioned and then the data transferred, hopefully just with labels instead of device names. > Sadly, I cannot use ZFS in this circumstance due to heavy memory requirements > of what the machine will be used for. A lot of legacy machines just can't accept enough memory for ZFS anyway.