This is an excerpt from bug 570332 and bug 495170 basically asking for better support in providing information about LVM2 devices without excessive scanning and opening all sorts of devices. Such information could be stored in persistent cache and provided on demand.

Excerpt from bug 570332:
Actually, liblvm2app does way more work that what udisks needs it to do.
Basically, what I like liblvm2app to do is

 - Open a block device given by me (/dev/sdx in the following)

 - Parse the LVM2 config file in the LVM2 PV superblock on the given
   block device /dev/sdx.

 - Make available vg_t, lv_t and pv_t objects based on _only_ what is
   stored on the block device /dev/sdx

 - In particular, when using liblvm2app this way the library should NOT
   - grab or rely on system-wide locks
   - open all sorts of unrelated block devices to try to give me more
     recent information than what's on the block device I originally specified.

Excerpt from bug 495170:
Btw, /lib/udev/rules.d/70-anaconda.rules is scary reading, there's this snippet

 # probe metadata of LVM2 physical volumes
 ENV{ID_FS_TYPE}=="LVM2_member", IMPORT{program}="$env{ANACBIN}/lvm pvs \
    --units k --nosuffix --nameprefixes --rows --unquoted --noheadings \
-opv_name,pv_uuid,pv_size,vg_name,vg_uuid,pv_pe_count,pv_pe_alloc_count,pe_start
$tempnode"

Do you realize just how expensive this operation is? With the way the LVM tools
currently work, each invocation is going to open all block devices. This is a
sure way to kill big boxes with many LVM PV's...