+++ 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.
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.)
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.
(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.
In lvm2-2.02.40-1.el5.
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