Date: Tue, 22 Sep 2015 12:12:42 -0700 From: Chris Stankevitz <chris@stankevitz.com> To: Matt Churchyard <matt.churchyard@userve.net> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: Name/label/id metadata: how do I make it go away Message-ID: <5601A82A.7040304@stankevitz.com> In-Reply-To: <e1abb521ab324532b3445d26984f5638@SERVER.ad.usd-group.com> References: <56004C68.4020904@stankevitz.com> <alpine.BSF.2.20.1509212126470.4544@wonkity.com> <5600F0DF.8000805@stankevitz.com> <e1abb521ab324532b3445d26984f5638@SERVER.ad.usd-group.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/22/15 1:15 AM, Matt Churchyard wrote: > The thing to be clear on is that although glabel is responsible for > creating the device nodes for most of these labels, the way they are > assigned is very different Matt, Thank you for your explanation. I will read the glabel(8) man page seeing that it is almost certainly responsible for what is going on -- even though glabel was not used to create the diskid. > diskid - Automatic based on the ID of the disk - so should reference > an entire disk I want to read the man page or source for whatever assigns diskid for glabel to subsequently advertise. That process, for some reason, only assigns diskids for 10 of my 22 drives. All drives are the same model number, although the drives have different histories. (some drives lived in FreeNAS in a former life) My running theory is that there is indeed some kind of metadata stored on the disk indicating a preference for or against diskid... but that it is "obfuscated". For example "if a disk formally had GPT, but the primary GPT table was overwritten and the secondary still exists at the end of the disk then diskid is/isn't used." Otherwise I cannot fathom why some of my identical disks advertise diskid while others do not. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5601A82A.7040304>