Red Hat Bugzilla – Bug 1271001
duplicate pvs can be missed by pvscan --cache
Last modified: 2016-06-10 16:47:21 EDT
Description of problem:
There are still problems with duplicate PVs not being reported with lvmetad.
The example I'm seeing now is:
# pvscan --cache
Found duplicate PV 6H5srHtbk2igv1OqBjJbg3r9vDlSZzlj: using /dev/sdd not /dev/sdc
Using duplicate PV /dev/sdd which is last seen, replacing /dev/sdc
Found duplicate PV maevmciDh8i0Sr6oQktfx9eCBYgvTwcY: using /dev/sdb not /dev/sde
Using duplicate PV /dev/sdb without holders, ignoring /dev/sde
Found duplicate PV 6H5srHtbk2igv1OqBjJbg3r9vDlSZzlj: using /dev/sdc not /dev/sdd
Using duplicate PV /dev/sdc which is last seen, replacing /dev/sdd
/dev/sdb lvm2 --- 931.01g 931.01g
/dev/sdc lvm2 --- 931.01g 931.01g
The sdd/sdc duplicates are handled like we want, but the sdb/sde duplicates are not recorded as duplicates in lvmetad, and subsequently not reported as duplicates from 'pvs'. This is because in the sdb/sde case, the first device is preferred over the second within the pvscan --cache command, so the second is never sent to lvmetad. The "preferred" selection between duplicates within lvmcache_add() is the correct behavior when it's used by a reporting command like pvs, but in the special case of 'pvscan --cache' where lvmetad is being populated, we want a different behavior that will just send all the info to lvmetad. When the command is just populating lvmetad, it doesn't really make sense to be using the lvmcache layer at all. If there's no alternative to using lvmcache here, a workaround might be to trick lvmcache_add() to always prefer the new duplicate device when called for pvscan --cache.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
It's unlikely that I'll have a the lvmetad duplicate PV handling reworked in time for 7.3.
New duplicate handling is done, and lvmetad is disabled while duplicates exist.