Date: Wed, 10 Feb 2010 10:29:13 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= <gerrit@pmp.uni-hannover.de> To: Marius =?ISO-8859-1?Q?N=FCnnerich?= <marius@nuenneri.ch> Cc: Elliot Finley <efinley.lists@gmail.com>, freebsd-stable@freebsd.org Subject: Re: zpool vdev vs. glabel Message-ID: <20100210102913.091f64ef.gerrit@pmp.uni-hannover.de> In-Reply-To: <b649e5e1002100118p14552a41r9bf7f48b540e5a74@mail.gmail.com> References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> <54e63c321002091227w15657c54oeb2295efc4c43980@mail.gmail.com> <20100210092412.5a06d98e.gerrit@pmp.uni-hannover.de> <b649e5e1002100118p14552a41r9bf7f48b540e5a74@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Feb 2010 10:18:49 +0100 Marius Nünnerich <marius@nuenneri.ch>
wrote about Re: zpool vdev vs. glabel:
MN> It seems there is some kind of race condition with zfs either picking
MN> up the disk itself or the label device for the same disk. I guess it's
MN> which ever it probes first.
This could explain it. However, it seems that zfs sticks to the da device
once it changed it's mind. Meanwhile I discovered one more system where is
obviously has happened (although I cannot say when:
luna# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1 ONLINE 0 0 0
label/disk-1 ONLINE 0 0 0
da0 ONLINE 0 0 0
label/disk-2 ONLINE 0 0 0
label/disk-3 ONLINE 0 0 0
errors: No known data errors
MN> I wrote the GPT part of glabel for using
MN> it in situations like this, I had not a single report of this kind of
MN> problem with the gpt labels. Maybe you can try them too?
Yeah, I just have to look into how gpt labels work. I did not use them at
all up to now.
cu
Gerrit
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100210102913.091f64ef.gerrit>