From owner-freebsd-stable@FreeBSD.ORG Tue Jul 7 23:20:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A59106564A; Tue, 7 Jul 2009 23:20:08 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 69DDD8FC16; Tue, 7 Jul 2009 23:20:07 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yxe11 with SMTP id 11so7466526yxe.3 for ; Tue, 07 Jul 2009 16:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1wz2wTBtkFo56cVui6kpiS+Xn71x3ty+PrEHyXEP4Q0=; b=tQC22uBmsW58BO7Kh3AEAeIDIVmh2fCC8Og3MwtjN9hy3SKwNOouWz1wlsCQuaKhnF BG4a6eoZe8EbsfieteeZNYLL72n1/h1Pzsuv/I9WSpd162CiGprbKKlxWuP/Ivl9OVGM g+UKi/69SFLJ171lwUuGmT0zdtHCT7mSSQwuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Y7myFZQOuzuvvK8vkK8jgbAdLTgK+HnOVMg0YXse9BkBbM/mWBYTZ9DXHtmt6apWPw tZqIki7BNn5oxCoK0R1D/ewek5M5xEAQ65p0nrF82azMIOt60b7ToVAvkLQz3s+Fw/XD bH9n+pxSYfO9YQHwAn2R+VMEWrftX4ElHQnWE= MIME-Version: 1.0 Received: by 10.100.195.15 with SMTP id s15mr11494872anf.18.1247008807465; Tue, 07 Jul 2009 16:20:07 -0700 (PDT) Date: Wed, 8 Jul 2009 02:20:07 +0300 Message-ID: From: Dan Naumov To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: glabel metadata protection (WAS: ZFS: drive replacement performance) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 23:20:09 -0000 >> Not to derail this discussion, but can anyone explain if the actual >> glabel metadata is protected in any way? 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? Or is every filesystem >> used by FreeBSD (ufs, zfs, etc) hardcoded to ignore the last few >> sectors of any disk and/or partition and not write data to it to avoid >> such issues? > > Disks labeled with glabel lose their last sector to the label. =A0It is n= ot > accessible by ZFS. =A0Disks with bsdlabel partition tables are at risk du= e to > the brain dead decision to allow partitions to overlap the first sector, > but modern designs like glabel avoid this mistake. > > -- Brooks 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? - Sincerely, Dan Naumov