Bug 225120 - kernel dumps to multi-disk gconcat volumes don't work
Summary: kernel dumps to multi-disk gconcat volumes don't work
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-12 21:49 UTC by Mark Johnston
Modified: 2018-01-12 23:03 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 Mark Johnston freebsd_committer freebsd_triage 2018-01-12 21:49:04 UTC
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.