From owner-freebsd-questions@freebsd.org Mon Jun 29 14:35:38 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB90798F620 for ; Mon, 29 Jun 2015 14:35:37 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1EB61BE8 for ; Mon, 29 Jun 2015 14:35:36 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by qcbcf1 with SMTP id cf1so43428848qcb.0 for ; Mon, 29 Jun 2015 07:35:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=VRfwPSI7wuZnZa2aC5h3diO6I17+RlmWXwveC0ZJL7Y=; b=MALQNISXGzqsK2UiiLv8rKsEs0WOaKdZuZt5gPuZjnR6yv8eJT8v5JpLgWGqhMSbO7 /w0t4Q20adqigWa8S+vUiWXoXAJXgM9t2Fr6o49LQrdmVt6qHPiT3rb8yieVl4P+lfq4 DFL2XqZJVVG/vmydFDWD1Nb01vU8AaOMxY+wBqVD4cdUzzEU/JQZW4FuWYabCGPeWPXq b7EEJHAj2ySXISYfXMotfzVeIuHaL/Zw6Lt3+W5MJ1rhymw+cBNFAglRyZmb98g6/ZVY 2qEgKHsnIkZ8ritL44seyDIqlbZ2NOzrD5lkqGDW8M8+pQO3Ex+KeV7L96QfIwhZkfpn vuuA== X-Gm-Message-State: ALoCoQlnAwk1mK6+j5gp459VCqtMsce3IjPNa6HRnCVsQBatp//e3LUtPmROYYSNrEPucmycnyMQ X-Received: by 10.140.28.99 with SMTP id 90mr19031933qgy.99.1435588179825; Mon, 29 Jun 2015 07:29:39 -0700 (PDT) Received: from mbp-1.thecreativeadvantage.com (mail.thecreativeadvantage.com. [96.236.20.34]) by mx.google.com with ESMTPSA id 47sm11575235qgt.15.2015.06.29.07.29.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jun 2015 07:29:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Corrupt GPT on ZFS full-disks that shouldn't be using GPT From: Paul Kraus In-Reply-To: Date: Mon, 29 Jun 2015 10:29:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5590A7AE.9040303@sneakertech.com> To: freebsd-questions X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 14:35:38 -0000 On Jun 29, 2015, at 10:19, Warren Block wrote: > On Sun, 28 Jun 2015, Quartz wrote: >=20 >>> Remember, ZFS >>> leaves space unused at the end of a disk to allow for variations in >>> nominal disk size. >>=20 >> Holy what the heck, no it doesn't! One big issue with zfs is that you = CANNOT shrink a pool's size once it's been created, for any reason. You = can't remove vdevs, and any replacement disk must bigger or exactly = equal in size; even a disk with one less sector and you're SOL. This is = my biggest gripe with zfs by far and in fact I just asked freebsd-fs = about this less than a week ago wondering if it had been addressed = finally (it hasn't). I do recall a change in ZFS behavior to leave a very small amount of = space unused at the every end of the drive to account for the = differences in real sizes between various vendors drives that were = nominally the same size. This only applied if you used the entire disk = and did not use any partitioning. This was in both the Solaris and = OpenSolaris versions of ZFS, so it predates the fork of the ZFS code. I have had no issues using disks of different manufacturers and even = models within manufacturers (which sometimes do vary in size by a few = blocks) as long as they were all the same nominal size (1 TB or 500 GB = in my case) and I had handed the entire disk to ZFS and not a partition. This is NOT an indication of any sort that you can shrink an existing = zpool nor does it imply that any given zpool is not writing to certain = blocks at the end of the disk, but that the space allocated by the zpool = create, when using an entire disk, leaves a little bit of wiggle room at = the end that is NOT part of the zpool. I will see if I can dig up the documentation on this. Note that it is a = very small amount as drives of the same nominal capacity vary very = little in real capacity. -- Paul Kraus paul@kraus-haus.org