Bug 232684 - [gmirror] gmirror overly aggressive provider destruction
Summary: [gmirror] gmirror overly aggressive provider destruction
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-geom (Nobody)
URL:
Keywords:
Depends on: 232671 232835
Blocks:
  Show dependency treegraph
 
Reported: 2018-10-25 16:27 UTC by Conrad Meyer
Modified: 2018-10-30 23:27 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Conrad Meyer freebsd_committer freebsd_triage 2018-10-25 16:27:40 UTC
+++ This bug was initially created as a clone of Bug #232671 +++

In the bug we cloned from, gmirror destroyed the root0 provider because the two disks it currently knew about were both invalid (one stale, one partially sychronized).  Transitioning to RUNNING with no ACTIVE disks is its own bug (the original we cloned) but in general gmirror is quick to kill itself when it enters a bad state.

I don't think this is necessarily a good idea.  It might be best to limp along in a degraded mode that ENXIO's all operations but allows (1) an administrator to re-plug devices to the system in case they had an ACTIVE mirror disk lying around disconnected or (2) maybe hardware was just slow to settle.

I haven't thought through the ramifications of this proposal thoroughly and it's possible this is nonsensical.  It's certainly a lower priority than the other two recent GEOM PRs I've filed.
Comment 1 Conrad Meyer freebsd_committer freebsd_triage 2018-10-25 16:28:55 UTC
Oh, and regardless of destruction *policy*, destruction itself should be a console-logged event like any CAM device's disappearance!  During mountroot the best clue we get is "root_mount_rel[2352] 0xppppppp" and that's *iff* GEOM debug level is set above zero.