https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225120
Bug ID: 225120
Summary: kernel dumps to multi-disk gconcat volumes don't work
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
g_concat_kernel_dump() configures kernel dumps to write to the first disk in
the request range:
219 for (i = 0; i < sc->sc_ndisks; i++) {
220 if (sc->sc_disks[i].d_start <= gkd->offset &&
221 sc->sc_disks[i].d_end > gkd->offset)
222 break;
223 }
When configuring a multi-disk gconcat device as the dump device, this means
that we'll never be able to recover kernel dumps. In particular, savecore(8)
looks for the trailing kernel dump header in the last sector of the provider.
Moreover, we can't even easily recover the kernel dump directly from the
provider for the first disk, since the last sector of that provider will
contain gconcat metadata. (It is possible to use gnop to trim off that last
sector, but that's a bit too manual.)
I think gconcat (and gmirror) should do what graid does, and implement their
own dumper functions which map writes to the corresponding disk(s), instead of
selecting a single disk and passing all writes through to it. This would
address this bug and fix the caveat described in the NOTES section of the
gmirror man page.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
