Gitweb: http://git.fedorahosted.org/git/?p=lvm2.git;a=commitdiff;h=cafde608909b87ae…
Commit: cafde608909b87aedeb76f0eda1397f7bf98fea4
Parent: bd75844024ad4a2e66c7743c50e189a00c233284
Author: Jonathan Brassow <jbrassow(a)redhat.com>
AuthorDate: Fri Sep 20 11:33:29 2013 -0500
Committer: Jonathan Brassow <jbrassow(a)redhat.com>
CommitterDate: Fri Sep 20 11:33:29 2013 -0500
test: Blacklist fedora-19 kernel for RAID4/5/6 dev replace tests
A know issue with kmem_cach is causing failures while testing
RAID 4/5/6 device replacement. Blacklist the offending kernel
so that these tests are not performed there.
---
test/lib/aux.sh | 33 +++++++++++++++++++++++++++++++++
test/shell/lvconvert-raid.sh | 2 ++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/test/lib/aux.sh b/test/lib/aux.sh
index 6194492..7939949 100644
--- a/test/lib/aux.sh
+++ b/test/lib/aux.sh
@@ -615,6 +615,39 @@ skip_if_mirror_recovery_broken() {
if test `uname -r` = 3.3.4-5.fc17.x86_64; then skip; fi
}
+skip_if_raid456_replace_broken() {
+# The way kmem_cache aliasing is done in the kernel is broken.
+# It causes RAID 4/5/6 tests to fail.
+#
+# The problem with kmem_cache* is this:
+# *) Assume CONFIG_SLUB is set
+# 1) kmem_cache_create(name="foo-a")
+# - creates new kmem_cache structure
+# 2) kmem_cache_create(name="foo-b")
+# - If identical cache characteristics, it will be merged with the previously
+# created cache associated with "foo-a". The cache's refcount will be
+# incremented and an alias will be created via sysfs_slab_alias().
+# 3) kmem_cache_destroy(<ptr>)
+# - Attempting to destroy cache associated with "foo-a", but instead the
+# refcount is simply decremented. I don't even think the sysfs aliases are
+# ever removed...
+# 4) kmem_cache_create(name="foo-a")
+# - This FAILS because kmem_cache_sanity_check colides with the existing
+# name ("foo-a") associated with the non-removed cache.
+#
+# This is a problem for RAID (specifically dm-raid) because the name used
+# for the kmem_cache_create is ("raid%d-%p", level, mddev). If the cache
+# persists for long enough, the memory address of an old mddev will be
+# reused for a new mddev - causing an identical formulation of the cache
+# name. Even though kmem_cache_destory had long ago been used to delete
+# the old cache, the merging of caches has cause the name and cache of that
+# old instance to be preserved and causes a colision (and thus failure) in
+# kmem_cache_create(). I see this regularly in testing the following
+# kernels:
+ if test `uname -r` = 3.10.11-200.fc19.i686; then skip; fi
+ if test `uname -r` = 3.10.11-200.fc19.x86_64; then skip; fi
+}
+
udev_wait() {
pgrep udev >/dev/null || return 0
which udevadm >/dev/null || return 0
diff --git a/test/shell/lvconvert-raid.sh b/test/shell/lvconvert-raid.sh
index 4c08386..6762db2 100644
--- a/test/shell/lvconvert-raid.sh
+++ b/test/shell/lvconvert-raid.sh
@@ -206,6 +206,8 @@ for i in {1..3}; do
lvremove -ff $vg
done
+aux skip_if_raid456_replace_broken
+
# RAID 4/5/6 (can replace up to 'parity' devices)
for i in 4 5 6; do
lvcreate --type raid$i -i 3 -l 3 -n $lv1 $vg
Gitweb: http://git.fedorahosted.org/git/?p=lvm2.git;a=commitdiff;h=f393a5c15631f883…
Commit: f393a5c15631f883883df41e85b3209b33005cd6
Parent: 2c41c8b88610bff6a3352b93f6b5c70a3744c817
Author: Peter Rajnoha <prajnoha(a)redhat.com>
AuthorDate: Fri Sep 20 09:42:27 2013 +0200
Committer: Peter Rajnoha <prajnoha(a)redhat.com>
CommitterDate: Fri Sep 20 09:45:34 2013 +0200
udev: remove unused line in 69-dm-lvm-metad.rules
The explicit check for *_raid_member is not actually needed as
this gets filtered out by the ENV{ID_FS_TYPE}!="LVM2_member|LVM1_member" rule.
---
udev/69-dm-lvm-metad.rules.in | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/udev/69-dm-lvm-metad.rules.in b/udev/69-dm-lvm-metad.rules.in
index 6363a79..ba43396 100644
--- a/udev/69-dm-lvm-metad.rules.in
+++ b/udev/69-dm-lvm-metad.rules.in
@@ -27,6 +27,7 @@ ENV{LVM_PV_GONE}=="1", GOTO="lvm_scan"
# Only process devices already marked as a PV - this requires blkid to be called before.
ENV{ID_FS_TYPE}!="LVM2_member|LVM1_member", GOTO="lvm_end"
+ENV{DM_MULTIPATH_DEVICE_PATH}=="1", GOTO="lvm_end"
# Inform lvmetad about any PV that is gone.
ACTION=="remove", GOTO="lvm_scan"
@@ -76,11 +77,6 @@ LABEL="lvm_scan"
# MD | | X | X* | |
# loop | | X | X* | |
# other | X | | X | | X
-
-# Skip device that is a multipath or RAID component
-ENV{DM_MULTIPATH_DEVICE_PATH}=="1", GOTO="lvm_end"
-ENV{ID_FS_TYPE}=="*_raid_member", GOTO="lvm_end"
-
RUN+="(LVM_EXEC)/lvm pvscan --background --cache --activate ay --major $major --minor $minor", ENV{LVM_SCANNED}="1"
LABEL="lvm_end"
Gitweb: http://git.fedorahosted.org/git/?p=lvm2.git;a=commitdiff;h=c2dd0a832a8f0647…
Commit: c2dd0a832a8f06471f86e8244884c4dc902cc9f7
Parent: 68f841fcda29ee0af177b0299b52842afcf1bae2
Author: Jonathan Brassow <jbrassow(a)redhat.com>
AuthorDate: Tue Sep 17 23:03:57 2013 -0500
Committer: Jonathan Brassow <jbrassow(a)redhat.com>
CommitterDate: Tue Sep 17 23:03:57 2013 -0500
man: lvs man page was not accurate on the volume health bit of lv_attr
The 'm'ismatches flag only shows after a "check" scrubbing operation -
not after a "check" or "repair" as indicated by the man page.
---
man/lvs.8.in | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/man/lvs.8.in b/man/lvs.8.in
index 8f97dc2..32cb788 100644
--- a/man/lvs.8.in
+++ b/man/lvs.8.in
@@ -173,12 +173,11 @@ more of the Physical Volumes this RAID Logical Volume uses had suffered a
write error. The write error could be due to a temporary failure of that
Physical Volume or an indication that it is failing. The device should be
refreshed or replaced. (m)ismatches signifies that the RAID logical volume
-has portions of the array that are not coherent or that the array has
-recently repaired inconsistencies. An additional "check" after a "repair"
-of a RAID logical volume will clear this flag if no additional discrepancies
-are found. ("check" and "repair" of a RAID Logical Volume can be done via
-the 'lvchange' command.) (w)ritemostly signifies the devices in a RAID 1
-logical volume that have been marked write-mostly.
+has portions of the array that are not coherent. Inconsistencies are
+detected by initiating a "check" on a RAID logical volume. (The scrubbing
+operations, "check" and "repair", can be performed on a RAID logical
+volume via the 'lvchange' command.) (w)ritemostly signifies the devices in
+a RAID 1 logical volume that have been marked write-mostly.
.IP 10 3
s(k)ip activation: this volume is flagged to be skipped during activation.
.RE