Red Hat Bugzilla – Bug 229560
RFE: lvm2 cache - write vg name in the .cache file
Last modified: 2012-04-12 08:45:45 EDT
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 problem ***
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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235092 "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. http://fedoraproject.org/wiki/LifeCycle/EOL 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 the change. 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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 person:-) 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 ***