From owner-freebsd-geom@FreeBSD.ORG Wed Jul 8 01:07:16 2009 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 A0407106564A; Wed, 8 Jul 2009 01:07:16 +0000 (UTC) (envelope-from bp@barryp.org) Received: from itasca.hexavalent.net (itasca.hexavalent.net [67.207.138.180]) by mx1.freebsd.org (Postfix) with ESMTP id 68C618FC0A; Wed, 8 Jul 2009 01:07:16 +0000 (UTC) (envelope-from bp@barryp.org) Received: from eden.barryp.org (host-145-114-107-208.midco.net [208.107.114.145]) by itasca.hexavalent.net (Postfix) with ESMTPS id C57B223C549; Tue, 7 Jul 2009 19:49:52 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=barryp.org; s=itasca; t=1247014192; bh=vqsypQSX/+1KSkQr+XN249Yxr9LIFW9LP6e3Giijunk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LOVzwbeVl1WD tlp+cs9ugo1j5WY6K0dASg7rUlWOFfIvfhgflaUC7U2+5vOU5TodNNX7an9ghl/OEV1 7gn25z0tpmXzAahpTnGvcoF7v+gou3qDelivao00KY0B5KGZVTt9cqjbdSPAqr5QcRL jjgtZn7cfwDhriuyIBn7DFv9Q= Received: from [10.66.1.233] (helo=barry-pedersons-macbook.local) by eden.barryp.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1MOLM6-0003Sm-He; Tue, 07 Jul 2009 19:49:50 -0500 Message-ID: <4A53ED2D.4070309@barryp.org> Date: Tue, 07 Jul 2009 19:49:49 -0500 From: Barry Pederson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel metadata protection (WAS: ZFS: drive replacement performance) 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, 08 Jul 2009 01:07:17 -0000 Dan Naumov wrote: >>> If I use glabel to label a >>> disk and then create a pool using /dev/label/disklabel, won't ZFS >>> eventually overwrite the glabel metadata in the last sector since the >>> disk in it's entirety is given to the pool? I would say in this case you're *not* giving the entire disk to the pool, you're giving ZFS a geom that's one sector smaller than the disk. ZFS never sees or can touch the glabel metadata. > So what happens if I was to do the following (for the same of example): > > gpart create -s GPT /dev/ad1 > glabel label -v disk01 /dev/ad1 > gpart add -b 1 -s -t freebsd-zfs /dev/ad1 > > Does "gpart add" automatically somehow recognize that the last sector > of contains the glabel and automatically re-adjusts this > command to make the freebsd-zfs partition take "entiredisk minus last > sector" ? I can understand the logic of metadata being protected if I > do a: "gpart add -b 1 -s -t freebsd-zfs > /dev/label/disk01" since gpart will have to go through the actual > label first, but what actually happens if I issue a gpart directly to > the /dev/device? I'd guess bad stuff would happen here, with a conflict between what gpt and glabel would want to do with the end of the disk. If you wanted to use glabel with a GPT partition, I'd think you'd want to gpart create -s GPT /dev/ad1 (use "gpart show" to see what space is now available for GPT partitions, it won't start at 1 and won't go to the very end of the disk) gpart add -b 34 -s -t freebsd-zfs /dev/ad1 glabel label -v disk01 /dev/ad1p1 (and then use label/disk01 in a zpool) Barry