Name/label/id metadata: how do I make it go away

[Karli Sjöberg]

tis 2015-09-22 klockan 14:43 -0700 skrev Chris Stankevitz:
> On 9/22/15 2:01 PM, Warren Block wrote:
> >> According to 'geom disk list', each of my 22 drives has an "ident",
> >> but only some of them have "labels".
> >>
> >> "ident" is turned into a "label" via a process called "tasting":
> >>  sys/geom/label/g_label_disk_ident.c
> >>  sys/geom/label/g_label.c
> >>
> >> Although it is not yet clear to me why apparently only some of my
> >> disks are "tasted".
> >
> > Labels on devices that are mounted are "withered" and disappear.
> 
> Thank you.
> 
> Indeed when I export the pool, all of the drives become listed in 
> /dev/diskid.  When I re-import the pool, some of the drives "wither" and 
> are removed from /dev/diskid.  These withered drives appear as daX in 
> "zpool status".  The drives that do not wither remain in /dev/diskid and 
> appear in "zpool status" with their /dev/diskid/X names.
> 
> Q: Why do my identical zpool drives behave differently?
> 
> Please let me know if my hypothesis is plausible:
> 
> ZFS sees both the /dev/daX "consumers" and the /dev/diskid/X 
> "providers".  ZFS is randomly selecting which to use to import the pool. 
>   Sometimes it picks "consumers" and sometimes "providers".
> 
> When ZFS picks a consumer, the provider is withered away.  When ZFS 
> picks a provider, the provider remains.
> 
> 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

Can´t say much about the rest but yeah, if you want the diskid's to go
away globally, that´s your ticket. If you´re only concerned about 'zpool
status' looking wierd, you can export the pool and then import it again
while specifying where ZFS should look for the providers:

# zpool import -d /dev <pool>

/K

> 
> Thank you again,
> 
> Chris
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"