| Summary: | kernel dumps to multi-disk gconcat volumes don't work | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Mark Johnston <markj> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | New --- | ||
| Severity: | Affects Some People | CC: | cem |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
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.