Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Jul 2009 01:40:02 +0300
From:      Dan Naumov <dan.naumov@gmail.com>
To:        Freddie Cash <fjwcash@gmail.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: ZFS: drive replacement performance
Message-ID:  <cf9b1ee00907071540u41128d3p528e1b240050d2f8@mail.gmail.com>
In-Reply-To: <b269bc570907071532ub95af78i6ad3a09e8c6887d7@mail.gmail.com>
References:  <20090707195614.GA24326@martini.nu> <b269bc570907071354r36015689ha362ba83413efc46@mail.gmail.com> <20090707222631.GA70750@martini.nu> <b269bc570907071532ub95af78i6ad3a09e8c6887d7@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 8, 2009 at 1:32 AM, Freddie Cash<fjwcash@gmail.com> wrote:
> On Tue, Jul 7, 2009 at 3:26 PM, Mahlon E. Smith <mahlon@martini.nu> wrote=
:
>
>> On Tue, Jul 07, 2009, Freddie Cash wrote:
>> >
>> > This is why we've started using glabel(8) to label our drives, and the=
n
>> add
>> > the labels to the pool:
>> > =A0 # zpool create store raidz1 label/disk01 label/disk02 label/disk03
>> >
>> > That way, it does matter where the kernel detects the drives or what t=
he
>> > physical device node is called, GEOM picks up the label, and ZFS uses =
the
>> > label.
>>
>> Ah, slick. =A0I'll definitely be doing that moving forward. =A0Wonder if=
 I
>> could do it piecemeal now via a shell game, labeling and replacing each
>> individual drive? =A0Will put that on my "try it" list.

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?


- Sincerely,
Dan Naumov



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