> @ilovezfs Actually, that problem does not apply on FreeBSD. (I wasn't even
> aware of it until I tried to test this patch on illumos last night, and found
> the behavior slightly odd.) On FreeBSD, what you see in 'zpool status' is
> what you get for zdb and 'zpool labelclear' purposes.
@wca OK, I fired up a FreeBSD 11 VM, and now understand why that is true.
FreeBSD's ZFS implementation, unlike illumos's, unlike ZoL's, and unlike O3X's,
does not partition whole disks it is given, and yet marks the device
whole_disk=1 on the label.
https://github.com/illumos/illumos-gate/blob/139510fb6efa97dbe5f5479594b308d940cab8d1/usr/src/cmd/zpool/zpool_vdev.c#L353-L360
```
/*
* By "whole disk" we mean an entire physical disk (something we can
* label, toggle the write cache on, etc.) as opposed to the full
* capacity of a pseudo-device such as lofi or did. We act as if we
* are labeling the disk, which should be a pretty good test of whether
* it's a viable device or not. Returns B_TRUE if it is and B_FALSE if
* it isn't.
*/
```
FreeBSD seems to have turned this upside down, insofar as it ends up marking
whole_disk=1 only on devices that do NOT have an EFI label (AKA GPT) and
whole_disk=0 only on devices that do. It also means that we cannot infer
partitioning, let alone any particular partition offsets or partition numbers
when we see whole_disk=1. I wonder if this was a design decision, a
misunderstanding of whole_disk, or both.
In addition, it means that when we see "sda" on Linux or "disk1" on OS X in
zpool status, we cannot infer that ZFS is on sda1 and disk1s1 even if we know
sda and disk1 are full physical devices, because the pool may have come from
FreeBSD.
I do question the wisdom of not partitioning full devices, especially when most
ZFS literature recommends giving ZFS full devices. An unintended consequence of
this advice is now that FreeBSD users are effectively being encouraged not to
use partitioning at all, which is dangerous, to say the least.
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/32#issuecomment-152783227
_______________________________________________
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
