Date: Fri, 12 Jan 2018 21:49:04 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 225120] kernel dumps to multi-disk gconcat volumes don't work Message-ID: <bug-225120-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225120 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@FreeBSD.org Reporter: markj@FreeBSD.org g_concat_kernel_dump() configures kernel dumps to write to the first disk in the request range: 219 for (i =3D 0; i < sc->sc_ndisks; i++) { 220 if (sc->sc_disks[i].d_start <=3D 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 provide= r. 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-225120-8>