Bug 461771

Summary:	Avoid unnecessary scanning devices multiple times in pv/vgscan
Product:	Red Hat Enterprise Linux 5	Reporter:	Milan Broz <mbroz>
Component:	lvm2	Assignee:	Milan Broz <mbroz>
Status:	CLOSED ERRATA	QA Contact:	Cluster QE <mspqa-list>
Severity:	high	Docs Contact:
Priority:	medium
Version:	5.3	CC:	agk, cmarthal, dwysocha, edamato, heinzm, jbrassow, mbroz, prockai, pvrabec, tyasui
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-01-20 21:46:39 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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