Bug 461771 - Avoid unnecessary scanning devices multiple times in pv/vgscan
Summary: Avoid unnecessary scanning devices multiple times in pv/vgscan
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2
Version: 5.3
Hardware: All
OS: All
medium
high
Target Milestone: rc
: ---
Assignee: Milan Broz
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-09-10 14:33 UTC by Milan Broz
Modified: 2013-03-01 04:06 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-20 21:46:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0179 0 normal SHIPPED_LIVE lvm2 bug-fix and enhancement update 2009-01-20 16:05:45 UTC

Description Milan Broz 2008-09-10 14:33:43 UTC
+++ This bug was initially created as a clone of Bug #252420 +++

lvmcache introduced kind of "regression" when lock event invalidates
cached PVs but that also causes vgscan command to reread disc too many
times.

Because vgscan locks global lock, we can optimize this case.

--- Additional comment from tyasui on 2008-09-02 14:43:44 EDT ---

(In reply to comment #18)

> You are tracing real physical device access or just function call?

Yeah, I'm tracing real physical device accesses. Logs attached in
#16, #17 show the sequence of I/Os by vgscan command.

> It is normal, that label_read() is called repeatedly, but it should be
> in log mentioned as "cached" - so it read cached data from memory if
> possible.
> 
> e.g.
> #label/label.c:270         Using cached label for /dev/sde1

Here is the ouputs by -vvvv option. I hope you could get the problem.

# 2.02.40-cvs/vgscan -vvvv 2>&1 | grep label.c
#label/label.c:160       /dev/sdg: lvm2 label detected     ^
#label/label.c:160       /dev/sdh: lvm2 label detected     | Issued in
#label/label.c:160       /dev/sdi: lvm2 label detected     | get_vgids()
#label/label.c:160       /dev/sdj: lvm2 label detected     V
#label/label.c:160       /dev/sdj: lvm2 label detected     ^ VG loops
#label/label.c:271         Using cached label for /dev/sdj V (vg-sdj)
#label/label.c:160       /dev/sdi: lvm2 label detected     ^
#label/label.c:160       /dev/sdj: lvm2 label detected *** | vg-sdi
#label/label.c:271         Using cached label for /dev/sdi V
#label/label.c:160       /dev/sdh: lvm2 label detected     ^
#label/label.c:160       /dev/sdi: lvm2 label detected *** | vg-sdh
#label/label.c:271         Using cached label for /dev/sdh V
#label/label.c:160       /dev/sdg: lvm2 label detected     ^
#label/label.c:160       /dev/sdh: lvm2 label detected *** | vg-sdg
#label/label.c:271         Using cached label for /dev/sdg V

The above results explain accesses to the previous devices which
are marked by "***", however, the RHEL5.2 commands do not issue
I/Os to them.

# /usr/sbin/vgscan -vvvv 2>&1 | grep label.c
#label/label.c:162       /dev/sdg: lvm2 label detected ^
#label/label.c:162       /dev/sdh: lvm2 label detected | Issued in
#label/label.c:162       /dev/sdi: lvm2 label detected | get_vgids()
#label/label.c:162       /dev/sdj: lvm2 label detected V
#label/label.c:162       /dev/sdj: lvm2 label detected ^ loop vg-sdj
#label/label.c:162       /dev/sdj: lvm2 label detected V
#label/label.c:162       /dev/sdi: lvm2 label detected ^ loop vg-sdi
#label/label.c:162       /dev/sdi: lvm2 label detected V
#label/label.c:162       /dev/sdh: lvm2 label detected ^ loop vg-sdh
#label/label.c:162       /dev/sdh: lvm2 label detected V
#label/label.c:162       /dev/sdg: lvm2 label detected ^ loop vg-sdg
#label/label.c:162       /dev/sdg: lvm2 label detected V

...

> If the cfg is one PV -> one VG you are right that scanning another device is
> unneccessary there.

Yes, I'm testing on one PV -> one VG configuration.

Comment 1 Milan Broz 2008-09-17 11:17:51 UTC
This should be fixed in upstream CVS by last commmit .
"Avoid repeatedly wiping cache while VG_GLOBAL is held in vgscan & pvscan"

(If you can run the tests above again to verify it, it would be nice, thanks.)

Comment 2 RHEL Program Management 2008-09-17 11:20:22 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 3 Takahiro Yasui 2008-09-18 19:01:38 UTC
(In reply to comment #1)
> This should be fixed in upstream CVS by last commmit .
> "Avoid repeatedly wiping cache while VG_GLOBAL is held in vgscan & pvscan"
> (If you can run the tests above again to verify it, it would be nice, thanks.)

I evaluated the latest version and found that the problems on vgscan is fixed.

On the other hand, pvscan is not affected by this fix. pvscan is differently
processed than the other commmands, such as vgscan and vgdisplay. pvscan does
not have this cache problem originally. I suggest that "pv" is removed from the
title of this Bugzilla to avoid confusion in the future.

CVS has the following change log, but I think that this is not correct, too.

date: 2008/09/16 18:05:11;  author: agk;  state: Exp;  lines: +1 -0
Avoid repeatedly wiping cache while VG_GLOBAL is held in vgscan & pvscan.

Comment 4 Milan Broz 2008-09-19 11:11:35 UTC
In lvm2-2.02.40-1.el5.

Comment 7 errata-xmlrpc 2009-01-20 21:46:39 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0179.html


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