Date: Wed, 23 Sep 2015 13:07:49 -0400 From: Paul Kraus <paul@kraus-haus.org> To: Chris Stankevitz <chris@stankevitz.com>, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Name/label/id metadata: how do I make it go away Message-ID: <93BD5F1D-9A64-4430-8519-FCF71E817A29@kraus-haus.org> In-Reply-To: <5601CB85.8070400@stankevitz.com> References: <56004C68.4020904@stankevitz.com> <alpine.BSF.2.20.1509212126470.4544@wonkity.com> <5600F0DF.8000805@stankevitz.com> <e1abb521ab324532b3445d26984f5638@SERVER.ad.usd-group.com> <5601A82A.7040304@stankevitz.com> <5601B2AF.7040306@stankevitz.com> <alpine.BSF.2.20.1509221500580.14674@wonkity.com> <5601CB85.8070400@stankevitz.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 22, 2015, at 17:43, Chris Stankevitz <chris@stankevitz.com> = wrote: > And if I want to dig deeper into root cause I can ask ZFS "why do you = sometimes select from the consumer collection and sometimes from the = provider collection when putting a pool together". Or if I don't want = to dig deeper I can "deal with it" or I can disable diskid using = kern.geom.label.disk_ident.enable Assuming 10.x, on boot the ZFS code scans all attached devices and = attempts to reassemble any zpools that it finds that were owned by this = system. I suspect which device ZFS uses is based on which it scans (and = finds) first. I actually prefer the /dev/diskid/nnn names as those are tied to the = physical drives. By using them I guarantee that even if a drive = physically (or logically if drives or controllers are added) moves the = system can still find and import the zpool. In the early days of ZFS one = of the best ways to damage a zpool was to rearrange drives so that the = ZFS label (and cache) no longer agreed with reality. I was in the habit = of manually exporting critical zpools before making any hardware changes = and after the changes were complete I would import the pool (sometime = with new device names). ZFS _should_ be robust enough to handle device = movement today, but I am slightly paranoid when it comes to critical = data. -- Paul Kraus paul@kraus-haus.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93BD5F1D-9A64-4430-8519-FCF71E817A29>