Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Jul 2009 02:20:07 +0300
From:      Dan Naumov <dan.naumov@gmail.com>
To:        Brooks Davis <brooks@freebsd.org>
Cc:        freebsd-stable@freebsd.org, freebsd-geom@freebsd.org
Subject:   glabel metadata protection (WAS: ZFS: drive replacement performance)
Message-ID:  <cf9b1ee00907071620i7a571be4w73aec90e97b3712a@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
>> 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 <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?

- Sincerely,
Dan Naumov



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cf9b1ee00907071620i7a571be4w73aec90e97b3712a>