|Summary:||[patch] [rc] gmirror savecore support|
|Product:||Base System||Reporter:||Paul J Murphy <paul>|
|Component:||conf||Assignee:||freebsd-bugs mailing list <bugs>|
|Severity:||Affects Only Me||CC:||christian.baltini|
Description Paul J Murphy 2014-05-23 20:10:00 UTC
(Calling this a sw-bug, rather than change-request, as I consider it a bug that savecore is basically broken on a very common setup.) Adding long-overdue basic gmirror savecore support. In a perfect world, it would support AUTO for simple configurations, but I've left that as a TODO for now, and think that it's better to get this basic support into the OS, and someone can figure out a nice AUTO implementation later. RC-wizards, please feel free to decide that the gmirror commands would be better executed inside the savecore_start() instead of pre/post. Also fixes doc-bugs in gmirror(8), which suggested addressing the issue through the removed rc.early/rc.late scripts, and removes mention of not being able to change priority of gmirror components (seems to work just fine on 10.0-RELEASE, not sure when it was fixed). Small section on boot on gmirror added to the NOTES section of gmirror(8), since there really should be some mention of that in there. Fix: Proposed for CURRENT & 10-STABLE. It should probably also go into older -STABLE too. This patch was developed and tested on 10.0-RELEASE, but can probably be easily applied to just about any recent-ish release. Is this simple and low-risk enough that it should go into existing releng branches as well? There's a possible small benefit in security terms, in that any attacks or exploits which end up causing a panic might be more detectable/diagnosable with this patch installed.
Comment 1 Mark Linimon 2014-05-24 18:13:19 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-rc Over to maintainer(s).
Comment 2 Lawrence Chen 2014-05-27 23:13:55 UTC
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. -- Name: Lawrence "The Dreamer" Chen Call: W0LKC Snail: 1530 College Ave, A5 Email: firstname.lastname@example.org Manhattan, KS 66502-2768 Blog: http://lawrencechen.net
Comment 3 Paul J Murphy 2014-05-28 12:11:56 UTC
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.
Comment 4 Eitan Adler 2017-12-31 08:01:09 UTC
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Comment 5 Christian Baltini 2019-06-11 05:37:57 UTC
I have provided my own workaround of sorts here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178818#c5