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:
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.
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.
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.
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.