Bug 181918 - GEOM: gmirror label (-h) doesn't cause /dev/mirror/ population or activation
Summary: GEOM: gmirror label (-h) doesn't cause /dev/mirror/ population or activation
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-geom (Nobody)
Depends on:
Reported: 2013-09-07 21:40 UTC by Charlie
Modified: 2020-10-28 05:20 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Charlie 2013-09-07 21:40:00 UTC
I try:

  $ gmirror label -h mymirror /dev/zvol/pool/component0.eli /dev/zvol/pool/component1.eli 

And nothing appears in /dev/mirror/.  I can confirm that "gmirror dump" shows metadata there.  But the mirrored setup isn't actually constructed so I can't use it.  It's also unclear to me how to best ask the kernel to manually try activating a GEOM label based upon written metadata.  Presently, a "geom activate" has no effect at all - exit status 0 and yet, still, nothing appears in /dev/mirror/.

How-To-Repeat: Try to create a gmirror GEOM setup as above.
Comment 1 Thomas Hurst 2015-03-21 10:52:20 UTC
Just encountered this myself - it's caused by the hardcoded device name being truncated to 15 characters.  In my case, adding gpt/voi.ssd.swap0 silently produced:

    hcprovider: gpt/voi.ssd.swa

Very stingy.  gmirror metadata looks to be pretty compact (135 bytes), so it should be able to support a good deal more.  Either way, it shouldn't just silently truncate.
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:52:17 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

- Set Status to "Open"