Date: Wed, 28 May 2014 11:20:00 GMT From: Paul J Murphy <paul@inetstat.net> To: freebsd-rc@FreeBSD.org Subject: Re: conf/190152: [patch] [rc] gmirror savecore support Message-ID: <201405281120.s4SBK0Pm085081@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR conf/190152; it has been noted by GNATS. From: Paul J Murphy <paul@inetstat.net> To: The BSD Dreamer <beastie@tardisi.com> Cc: Bug followup <bug-followup@freebsd.org> Subject: Re: conf/190152: [patch] [rc] gmirror savecore support Date: Wed, 28 May 2014 11:11:56 +0000 On Tue, May 27, 2014 at 05:13:55PM -0500, The BSD Dreamer wrote: > This sounds/looks similar to an issue I had reported as: > > docs/178818: gmirror(8) says to use rc.early which is no longer available > > Where there was a suggestion to handle it through the dumpon script, which I > more recently found that the savecore script should have a corresponding mod > as well. > > The timestamp on my current savecore is May 12th. And, my system > successfully saved crash dumps from May 11th and May 13th. > > The problem after the May 11th savecore, was that it didn't restore my > balance setting. I didn't look at the May 13th one....since I'm without a > mirror now. No panics since, perhaps that was the reason. Yes, it's basically the same problem as docs/178818. I didn't spot that PR when submitting this one, as I wasn't thinking "docs". As far as I'm aware, the problem doesn't actually need any changes to the dumpon script, as the kernel will always deterministically pick 1 physical device within the mirror when dumping. The problem comes when savecore tries to read the saved dump, and needs the dump device to give the same deterministic behaviour when reading from it. It's quite possible that there is a configuration where changes are needed to dumpon as well as savecore, but I don't know what that configuration is. If you know of a configuration which needs special handling there (as well as during savecore), please provide any details that you can. I believe that my patch here is sufficient for the 2 most obvious cases with a simple pair of simple drives (i.e. JBOD, with no complex RAID hardware involved): 1) entire-disk gmirror; 2) single-partition gmirror. There's also a problem with the fix suggested in docs/178818, I think, where it will fail on entire-disk gmirrors (i.e. where the mirror is /dev/mirror/gm0, with dump on a partition inside the mirror at, e.g., /dev/mirror/gm0b or /dev/mirror/gm0s1b). That is why I provided a "savecore_gmirror_name" conf var in my patch here, and avoided implementing AUTO for now. It's certainly possible for someone to implement AUTO in the future, which is why I left a TODO stub for it in my patch, but it's more complex to reliably determine the mirror name from the dump device than the simple stripping of "/dev/mirror" attempted in docs/178818. Regards, Paul.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405281120.s4SBK0Pm085081>