Hello, superblock version naming in mdadm is inconsistent, which cause a minor problem. For example, it is common to mantain /etc/mdadm.conf by simply redirecting mdadm output: mdadm --detail --scan > /etc/mdadm.conf If v1.2 superblock was created, it is then reported by mdadm as 1.02, e.g: mdadm --detail --scan ARRAY /dev/md0 level=raid0 num-devices=2 metadata=1.02 name=0 UUID=18c0f507:e7b96e85:ee9a3cec:f9d2e324 If one is to put 'metadata=1.02' back onto the command line to mdadm, it will complain about uknown superblock version. Reproducible: Always Steps to Reproduce: 1. create a RAID array with metadata=1,2 2. run 'mdadm --detail --scan' Actual Results: metadata=1.02 Expected Results: metadata=1.2 The kernel (through /proc/mdstat) reports superblock version correctly.
Sorry, there is a typo in the 'Steps to Reproduce'. I meant metadata=1.2 not metadata=1,2.
Created attachment 189079 [details] emerge --info
does mdadm-2.6.9 work ?
(In reply to comment #3) > does mdadm-2.6.9 work ? No. Just tested: it exibits the same behavior.
mdadm-3.0 seems to work for me # dd if=/dev/zero of=disk1 count=100000 # dd if=/dev/zero of=disk2 count=100000 # losetup /dev/loop1 disk1 # losetup /dev/loop2 disk2 # mdadm --detail --scan <no output> # mdadm -C /dev/md0 -e 1.2 -l raid0 -n 2 /dev/loop[12] mdadm: /dev/loop1 appears to be part of a raid array: level=raid0 devices=2 ctime=Mon Aug 24 02:13:28 2009 mdadm: /dev/loop2 appears to be part of a raid array: level=raid0 devices=2 ctime=Mon Aug 24 02:13:28 2009 Continue creating array? y mdadm: array /dev/md0 started. # mdadm --detail --scan > mdadm.conf # cat mdadm.conf ARRAY /dev/md0 metadata=1.02 name=vapier:0 UUID=5c6624bf:82c049cf:c981d09f:47bba378 # mdadm --stop /dev/md0 mdadm: stopped /dev/md0 # mdadm -As -c ./mdadm.conf mdadm: /dev/md0 has been started with 2 drives.
Hi SpanKY, I don't know why mdadm-3.0 works for you; I was playing only with 2.6.9, the latest in the portage tree. Anyway please note the discrepancy in the output you provided: 1.02 reported as opposed to -e 1.2 you initially specified. Perhaps the logic of interpreting config (and command line) input has changed to tolerate incorrect metadata=... input but the discrepancy is still in place.
i know the discrepancy is there, but mdadm-3.0 appears to parse it fine it depends on how you interpret the #'s. i see them as major.minor integers, not a float. so 1.2 == 1.02 == 1.002 == 1.000000002. considering the bug is trivial, i'm not planning on backporting anything to stable
