Bug 1571885

One of the reason why the  cache file was dropped - was it's usage of udev device list.

So cache file with list of block devices itself become obsoleted - since all known block devices in the system are now listed from udev.

So naturally udev could be seen as a good place where to store information about VG/PV uuid - so while getting list of devices from udev - we could also obtain list of VGs/PVs.

The catch however seems to be coming from problematic usage of udev  with duplicates and other unpredictable error behavior.

So the current existing reason why lvm2 still relies in almost all cases on its own scanning.

Adding support for maintenance of caching files (probably stored somewhere in  /run/lvm/cache  directory) clearly means to put a some code into keeping directory consistent -  but that also means new udev machinery to keep cachec in sync - and we have not managed to get it right for lvmetad.

So IMHO we inevitably hit likely same issues we are observing with lvmetad with a caching files as well - so my best impression here is -  udev needs to be fixed - and almost are problem will magically disappear.

The clear advantage would be - there would be no 'daemon' consuming memory resources uselessly most of the time and of course we can drop lots of code that sits in lvmetad and duplicated/replicated lvm2 command handling and MUCH more simpler testing ;) - since we do care about less daemons!

The minor disadvantage - it could be possibly a bit slower and consumes ramdisk.
and we get new 'locks' into commands that were previously hidden in lvmetad for updating of cache dir.

(In reply to Zdenek Kabelac from comment #2)
> One of the reason why the  cache file was dropped - was it's usage of udev
> device list.
> 

I think the reason was more in the fact that when we used /etc/lvm/cache/.cache file, we needed to run vgscan after a new device was addeded to system (also documented for our users here https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Cluster_Logical_Volume_Manager/vgscan.html).

With the obtain_device_list_from_udev=1, we had the opportunity to stop using the .cache file. But not because it wouldn't be useful much (iirc, it contained the result of last filter-chain execution from last LVM command so some of the filter didn't need to be reexecuted again), but we stopped using it because there were various other bugs reported related to its use. So the obtain_device_list_from_udev=1 was just an "excuse" to stop using .cache file. However, we could still use it even with obtain_device_list_from_udev=1 - this one only gets list of block devices from udev, but we could still apply persistent filter to it so we don't need to reexecute the whole filter chain again.

The issue is, the .cache file was problematic (various bugs reported against that) and we needed to get rid of it and we rather applied the filter chain again.

As for filtering, we can reuse information that is already available in udev by using external_device_info_source="udev" (e.g. that way we can read info about MD components, mpath components and similar so we don't need to reexecute the filters that access the device directly ourselves).

I suggest that we narrow the scope of this hint file to one or two simple, common cases.  Start with a command like 'vgs foo', which generally should only need to read the PVs for the named VG.  In this case, if the hint file contained:

device vgname seqno

sda foo 5
sdb foo 5
sdc foo 5

then the vgs command could begin by just scanning those three devices, which usually entails a single read i/o to each one.  After this scan, we would check that the seqno we saw from the scan from each of those devs matched the seqno from the hint file.  If so, we'd continue to vg_read and command processing, without any other reading.  Can anyone think of problematic cases with this example?

One file is likely a problem - since we now would need to maintain it's updating - and possibly serialize all unrelated VGs on access to 1 single file.
So IMHO that exclude single file.

Also the amount of info we need to store should probably list

PV, LV, VG  - all names + all UUID

So it can 'speedup' access without scanning for it.

One lost feature in time was -  lvm2 used the do 'lite-scan' based on content of device cache - when device was not there - fallback to full scan.
Unsure how this now would play back together.