[Bug 232684] [gmirror] gmirror overly aggressive provider destruction

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Oct 25 16:27:42 UTC 2018


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232684

            Bug ID: 232684
           Summary: [gmirror] gmirror overly aggressive provider
                    destruction
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: cem at freebsd.org
                CC: geom at FreeBSD.org, markj at FreeBSD.org
        Depends on: 232671
            Blocks: 232683

+++ 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.


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232671
[Bug 232671] [gmirror] gmirror fails to recover from degraded mirror sets in
some circumstances
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232683
[Bug 232683] [gmirror] gmirror could provide much better administrative
introspection into decision-making processes
-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list