Date: Mon, 07 Dec 2009 15:06:46 -0600 From: "James R. Van Artsdalen" <james-freebsd-fs2@jrv.org> Cc: freebsd-fs <freebsd-fs@FreeBSD.org>, Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: Re: ZFS and reordering drives Message-ID: <4B1D6E66.4000700@jrv.org> In-Reply-To: <20091206122603.GD2339@garage.freebsd.pl> References: <20091205170400.GM73250@gremlin.foo.is> <8555674.871260033069220.JavaMail.root@zimbra> <20091205184112.GP73250@gremlin.foo.is> <5da0588e0912051052p25fb743ele098ed9cb9de8fa0@mail.gmail.com> <20091205190641.GQ73250@gremlin.foo.is> <20091205191526.GR73250@gremlin.foo.is> <CA100C20-5F93-4DCE-B576-474DAEC10747@multipart-mixed.com> <20091206122603.GD2339@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote: > but there was a small > bug, which I fixed yesterday, where guid wasn't checked if name matched. After looking at the change and thinking about this I think there is still a problem. Consider a pool consisting of da1, da2 and da3. Assume da2 fails hard such that it is no longer seen by the system. When the pool is imported da1 is attached by PATH since the GUID matches when zpool.cache expects. But when da2 is attached: 1. Attach by PATH & GUID fails even though there is a /dev/da2 (what was da3) the GUID does not match. 2. Attach by GUID using GEOM search fails since da2 is no longer visible and no disk has that GUID. 3. Attach by PATH falsely succeeds since the PATH exists even though the GUID is wrong. Furthermore, attempts to attach da3 fail since it was already attached above. The result, at least, might be a RAIDZ that should only DEGRADED being FAULTED instead. I don't see any way to fix this without callers specifying whether a device is being added to a pool (don't check GUID) or merely attached as part of a pool (always check GUID).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B1D6E66.4000700>