Bug 586791 - Add support for persistent cache
Summary: Add support for persistent cache
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Petr Rockai
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 229560 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-28 11:46 UTC by Peter Rajnoha
Modified: 2013-03-18 14:21 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-18 14:21:26 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Peter Rajnoha 2010-04-28 11:46:57 UTC
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...

Comment 1 Peter Rajnoha 2010-04-28 12:06:36 UTC
(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.

Comment 2 Bug Zapper 2010-07-30 11:29:51 UTC
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

Comment 3 Peter Rajnoha 2012-04-11 12:55:35 UTC
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.

Comment 4 Peter Rajnoha 2012-04-12 12:45:45 UTC
*** Bug 229560 has been marked as a duplicate of this bug. ***

Comment 5 Petr Rockai 2013-03-18 14:21:26 UTC
I guess we don't really need a tracker for this anymore.


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