Bug 232684

Summary:	[gmirror] gmirror overly aggressive provider destruction
Product:	Base System	Reporter:	Conrad Meyer <cem>
Component:	kern	Assignee:	freebsd-geom (Nobody) <geom>
Status:	New ---
Severity:	Affects Some People	CC:	markj
Priority:	---
Version:	CURRENT
Hardware:	Any
OS:	Any
Bug Depends on:	232671, 232835
Bug Blocks:

Description Conrad Meyer freebsd_committer

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

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.