[Bug 225120] kernel dumps to multi-disk gconcat volumes don't work

[bugzilla-noreply at freebsd.org]

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: freebsd-bugs at FreeBSD.org
          Reporter: markj at FreeBSD.org

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.