glabel metadata protection (WAS: ZFS: drive replacement
bp at barryp.org
Wed Jul 8 01:07:17 UTC 2009
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 <ENTIREDISK> -t freebsd-zfs /dev/ad1
> Does "gpart add" automatically somehow recognize that the last sector
> of <ENTIREDISK> 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 <ENTIREDISK> -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
gpart add -b 34 -s <REMAININGDISK> -t freebsd-zfs /dev/ad1
glabel label -v disk01 /dev/ad1p1
(and then use label/disk01 in a zpool)
More information about the freebsd-stable