Bug 229560 - RFE: lvm2 cache - write vg name in the .cache file
Summary: RFE: lvm2 cache - write vg name in the .cache file
Keywords:
Status: CLOSED DUPLICATE of bug 586791
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Petr Rockai
QA Contact: Corey Marthaler
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-02-21 20:02 UTC by Dave Wysochanski
Modified: 2012-04-12 12:45 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-04-12 12:45:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dave Wysochanski 2007-02-21 20:02:42 UTC
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 ***

Comment 1 Dave Wysochanski 2007-02-23 18:07:29 UTC
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.

Comment 2 Dave Wysochanski 2007-04-24 16:17:36 UTC
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).

Comment 3 Bug Zapper 2008-04-04 06:19:46 UTC
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

Comment 4 Milan Broz 2008-04-04 06:48:11 UTC
(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...

Comment 5 Milan Broz 2008-04-04 06:51:33 UTC
Moving back to ASSIGNED.
(I thought that checkbox "I am providing the requested information for this
bug." had some meaning here, *sigh*). 

Comment 6 Jon Stanley 2008-04-23 20:28:37 UTC
Adding FutureFeature keyword to RFE's.

Comment 7 Peter Rajnoha 2012-04-12 12:45:45 UTC
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 ***


Note You need to log in before you can comment on or make changes to this bug.