From owner-freebsd-stable@FreeBSD.ORG Sun Jun 2 21:27:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 206296F4 for ; Sun, 2 Jun 2013 21:27:05 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id D55591992 for ; Sun, 2 Jun 2013 21:27:04 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r52LR3uM011360; Sun, 2 Jun 2013 15:27:03 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r52LR3p5011357; Sun, 2 Jun 2013 15:27:03 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 2 Jun 2013 15:27:03 -0600 (MDT) From: Warren Block To: Dmitry Morozovsky Subject: Re: Corrupt GPT header on disk from twa array - fixable? In-Reply-To: Message-ID: References: <7ABBEE71A96E411793E41BD97DA72BCE@multiplay.co.uk> <2943982C-719E-45D0-9B26-43B725738F83@gmail.com> <3659A498-F0EA-4AF3-80EA-40038DCA9CC7@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) 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]); Sun, 02 Jun 2013 15:27:03 -0600 (MDT) Cc: Kimmo Paasiala , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 21:27:05 -0000 On Mon, 3 Jun 2013, Dmitry Morozovsky wrote: > On Sun, 2 Jun 2013, Warren Block wrote: > > [snip] > >> gmirror is good. GPT is also good. The combination is a problem. gmirror >> metadata overwrites the backup GPT, so those disks will show "corrupt" also. >> For now, the recommended workaround is to just use MBR, which doesn't have any >> metadata at the end of the disk. > > ... or gmirror not whole disks, but GPT partitions (as OP does, as far as I can > tell from gmirror dmesg reports) That works, but if there is more than one partition per disk, rebuilds fight with each other for the heads.