Red Hat Bugzilla – Bug 586791
Add support for persistent cache
Last modified: 2013-03-18 10:21:26 EDT
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...
(In reply to comment #0) > Excerpt from bug 570332: > - Make available vg_t, lv_t and pv_t objects based on _only_ what is > stored on the block device /dev/sdx Let's correct this one requirement... Considering the planned persistent cache, we won't provide information that is *only* stored on one exact block device, but we will provide the most recent information we will have in the cache. That means, including information about related VG even if that PV does not contain metadata, but we already have read metadata from another PV that references this PV.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Persistent cache is provided by new "lvmetad" - the LVM metadata daemon which is upstream already, but it's still in active development (and not enabled in current Fedora yet). Let's keep this bz open to collect any related issues, problems and to track the progress.
*** Bug 229560 has been marked as a duplicate of this bug. ***
I guess we don't really need a tracker for this anymore.