Corrupt GPT on ZFS full-disks that shouldn't be using GPT

[Paul Kraus]

On Jun 29, 2015, at 10:19, Warren Block <wblock at wonkity.com> wrote:

> On Sun, 28 Jun 2015, Quartz wrote:
> 
>>> Remember, ZFS
>>> leaves space unused at the end of a disk to allow for variations in
>>> nominal disk size.
>> 
>> 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 at kraus-haus.org