Description of problem:

There are still problems with duplicate PVs not being reported with lvmetad.
The example I'm seeing now is:

# lvmetad

# 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

# pvs
  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):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: