When processing a PV that appears to be an orphan but contains an ignored mda,
a scan needs to be triggered before the VG name field can be relied upon.
> pvs -o +mda_count,vg_mda_count /dev/loop
PV VG Fmt Attr PSize PFree #PMda #VMda
/dev/loop0 vg3 lvm2 a- 96.00m 96.00m 0 1
/dev/loop1 vg3 lvm2 a- 96.00m 96.00m 1 1
/dev/loop2 vg2 lvm2 a- 96.00m 96.00m 1 2
/dev/loop3 vg2 lvm2 a- 28.00m 28.00m 1 2
> pvs /dev/loop2 /dev/loop3 /dev/loop0 /dev/loop1 --unbuffered
PV VG Fmt Attr PSize PFree
/dev/loop2 lvm2 a-- 100.00m 100.00m
/dev/loop3 vg2 lvm2 a-- 28.00m 28.00m
/dev/loop0 lvm2 a-- 100.00m 100.00m
/dev/loop1 vg3 lvm2 a-- 96.00m 96.00m
The blank VG entries should contain vg2 and vg3.
In process_each_pv() if we haven't yet scanned and the PV appears
to be an orphan, we must scan the other PVs looking for mdas that
reference it to find out what VG it is in.
1. If the PV has no mdas, we must scan.
2. If the PV has an mda that is not ignored we do not need to scan.
3. If the PV has an mda that is ignored, we do need to scan.
Bug dates back to the introduction of ignored mdas in 2.02.69 in June 2010.
Adding QA ack for 6.4.
Devel will need to provide unit testing results however before this bug can be
ultimately verified by QA.
See the linked commit message - testing involves creating PVs with/without mdas, putting them into VGs, then running 'pvs' with the PVs listed in various orders and seeing that the output in the VG column is always correct and doesn't depend on the order of the PVs on the command line.
Tested and marking verified with
The order of PVs in pvs did not change the output when there was a mix of MDA-containing and MDA-ignored devices.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.