Description of problem: (rough notes from Stuttgart '06, I think agk was speaking)
vg metadata is currently stored on the pvs (one copy on each pv); when we
read the volume group, we are given on the command line a name of the vg;
- when lvm starts up, it does not know what "vg0" is; it has to scan through
everything in /dev/... filtering out everything that obviously do not have
metadata on it, and figure out what "vg0" is.
- 1st level of addressing this problem: build up a cache, and remember what
"vg0" is for the next time; but this only survives a single tool
invocation, but this is stored in /etc/lvm/.cache; unfortunately, that
code never got finished - the only thing it writes into that file is
a list of devices with pvs on them
*** this seems to be very high priority, based on the boot / udev / hotplug
I think what this item was describing was a vg section in the cache that listed
pvs for that vg. The code could validate it by just reading those pvs first
rather than scanning everything.
I need to be thinking about this along with other cache issues. One issue was
brought up by brassow in today's lvmteam concall - the fact that labels/metadata
gets read multiple times and may become a big problem under load. I think the
specific issue jon brought up is captured here:
"clvmd operations timeout under heavy load == bad for recovery scenarios"
There may be other bz's I will file as we get into the specific issues (such as
multiple label_reads on the same device for a single command).
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
(In reply to comment #3)
> Fedora apologizes that these issues have not been resolved yet. We're
> sorry it's taken so long for your bug to be properly triaged and acted
> on. We appreciate the time you took to report this issue and want to
> make sure no important bugs slip through the cracks.
Well, this sounds a little bit odd when the reporter and assignee is the same
Anyway, part of this problem mentioned in bug is solved now by internal VG cache.
We will see if there is still need for extending .cache file.
In the meantime I move this to rawhide or some bot will close this...
Moving back to ASSIGNED.
(I thought that checkbox "I am providing the requested information for this
bug." had some meaning here, *sigh*).
Adding FutureFeature keyword to RFE's.
The .cache is obsolete now. Actually, this feature is now part of the lvmetad - the LVM metadata daemon together with event-based, single-device-only scanning initiated from within udev rules that consequently updates the daemon state.
I think we can close this bug as dup of #586791. Please, add any new comments there.
*** This bug has been marked as a duplicate of bug 586791 ***