Bug 752156 - mdadm --examine --brief output is inconsistent across metadata versions
mdadm --examine --brief output is inconsistent across metadata versions
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Doug Ledford
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-08 12:24 EST by David Lehman
Modified: 2011-11-10 23:12 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-08 12:42:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Lehman 2011-11-08 12:24:55 EST
Description of problem:
mdadm --examine --brief shows the metadata version for v1 but not for v0. This is inconsistent and makes it unnecessarily difficult to determine the metadata version of existing v0 arrays that are not currently active.

Version-Release number of selected component (if applicable):
mdadm-3.2.2-13.fc16

How reproducible:
Always

Steps to Reproduce:
1. Deactivate a v0 array
2. Run mdadm --examine --brief on one of its member devices
3.
  
Actual results:
v0: lists array name, UUID
v1: lists array name, UUID, and metadata version

Expected results:
same fields for both so that the command can be used to determine metadata version

Additional info:
Comment 1 David Lehman 2011-11-08 12:29:29 EST
This broke anaconda's ability to determine metadata version for preexisting v0 arrays, which will prevent people from using them for /boot in F16 (bug 750480). It never occurred to me that the examine/brief output would omit this info for some metadata versions.
Comment 2 Doug Ledford 2011-11-08 12:39:37 EST
I'm pretty sure Neil did this as a back compatibility thing.  If you were to run mdadm -Eb > mdadm.conf and then try to read that mdadm.conf file with an older mdadm version that didn't know about version 1.x superblock arrays, and we specified an array as having metadata version 0.90, then the older mdadm tool would choke on the file (it would also obviously choke if you had any version 1.x arrays).  Likewise for back compatibility with people's custom scripts, the output of /proc/mdstat does not include the array's version for version 0.90 arrays.  So, even though the default array type we create now is version 1.2, for the output of mdadm -E, mdadm -D, mdadm -Q, and /proc/mdstat, no version means version 0.90, and all other versions will have their version specified.  So the simple answer to your issue is to pre-set the version to 0.90, and only if a version string is present in the output, override the pre-set version.
Comment 3 David Lehman 2011-11-08 14:15:22 EST
I think that coherent, consistent tools are more important than backward-compatibility, especially when you are talking about being able to run an mdadm.conf generated on a new system using a (very) old version of mdadm. That's useless IMO.
Comment 4 Doug Ledford 2011-11-10 23:12:59 EST
The tool *is* coherent and consistent, just not in the way that you expected ;-)

Implement what I mentioned in comment #2 and both backward compatibility and consistency are served.  I get that it caught you off guard, that's entirely understandable from someone coming in from the outside that wasn't there when the decision was made to handle things this way, and it's entirely possible that documentation of this behaviour is lacking.  But that doesn't make the behaviour wrong.

Note You need to log in before you can comment on or make changes to this bug.