Fix additional mdadm parsing cases #346
Conversation
|
Of course, there's now a merge conflict. :-( |
…e unknown Assumes all raid configurations start with raid and that anything else is unknown.
|
Working on it. This is cause two fixes for the super 1.2x token are going in, so no surprise. Rebasing my branch and fixing conflicts. |
mcdan
force-pushed
the
people/mcdan/issues/219
branch
from
525e349 to
1f6b5ae
Compare
|
Updated the PR title to be more in line with our changelog naming style. For linking reference, this fixes #219 |
| statuslineRE = regexp.MustCompile(`(\d+) blocks .*\[(\d+)/(\d+)\] \[[U_]+\]`) | ||
| raid0lineRE = regexp.MustCompile(`(\d+) blocks( super ([0-9\.])*)? \d+k chunks`) | ||
| buildlineRE = regexp.MustCompile(`\((\d+)/\d+\)`) | ||
| unknownPersonalityLine = regexp.MustCompile(`(\d+) blocks (.*)`) |
| for _, possiblePersonality := range mainLine { | ||
| if raidPersonalityRE.MatchString(possiblePersonality) { | ||
| personality = possiblePersonality | ||
| // break |
There was a problem hiding this comment.
Are multiple personalities supported? are we just aiming to match the last?
Either uncomment the break, or remove it
There was a problem hiding this comment.
I don't think a raid array can have many personalities. Today the code isn't really setup to handle that either, it determines the personality of array and then uses one of the other REs to locate the data it wants. I think this break got juggled around with the merge conflicts, I'm going to add it back in.
| @@ -158,19 +175,28 @@ func parseMdstat(mdStatusFilePath string) ([]mdStatus, error) { | |||
| } | |||
| currentMD = mainLine[0] // The name of the md-device. | |||
| isActive := (mainLine[2] == "active") // The activity status of the md-device. | |||
| personality = mainLine[3] // The personality type of the md-device. | |||
| personality = "" | |||
| for _, possiblePersonality := range mainLine { | |||
There was a problem hiding this comment.
Ah yes good catch, the personality should only be in the 3rd item
There was a problem hiding this comment.
You're correct, good catch.
Signed-off-by: Wisniewski, Krzysztof2 <Krzysztof2.Wisniewski@intel.com>
Rebased correctly, couldn't reopen PR so this duplicates closed PR #312