Gitweb: http://git.fedorahosted.org/git/?p=lvm2.git;a=commitdiff;h=2d3700ba42e156aa…
Commit: 2d3700ba42e156aa8b6e2819736cab6866ea56ce
Parent: d2d71330c308230065dbc865e4552a9a62aad269
Author: Zdenek Kabelac <zkabelac(a)redhat.com>
AuthorDate: Thu May 2 18:06:50 2013 +0200
Committer: Zdenek Kabelac <zkabelac(a)redhat.com>
CommitterDate: Fri May 3 15:43:52 2013 +0200
report: improve reporting of active state
For reporting stacked or joined devices properly in cluster,
we need to report their activation state according the lock,
which activated this device tree.
This is getting a bit complex - current code tries simple approach -
For snapshot - return status for origin.
For thin pool - return status of the first known active thin volume.
For the rest of them - try to use dependency list of LVs and skip
known execptions. This should be able to recursively deduce top level
device for given LV.
(in release fix)
---
lib/metadata/lv.c | 40 +++++++++++++++++++++++++++++++++++++++-
lib/metadata/lv.h | 1 +
2 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/lib/metadata/lv.c b/lib/metadata/lv.c
index 41de7a5..283b8c4 100644
--- a/lib/metadata/lv.c
+++ b/lib/metadata/lv.c
@@ -745,6 +745,12 @@ char *lv_active_dup(struct dm_pool *mem, const struct logical_volume *lv)
{
const char *s;
+ if (vg_is_clustered(lv->vg)) {
+ //const struct logical_volume *lvo = lv;
+ lv = lv_lock_holder(lv);
+ //log_debug("Holder for %s => %s.", lvo->name, lv->name);
+ }
+
if (!lv_is_active(lv))
s = ""; /* not active */
else if (!vg_is_clustered(lv->vg))
@@ -755,7 +761,39 @@ char *lv_active_dup(struct dm_pool *mem, const struct logical_volume *lv)
"local exclusive" : "remote exclusive";
else /* locally active */
s = lv_is_active_but_not_locally(lv) ?
- "remotely" : "locally";
+ "remotely" : "locally";
return dm_pool_strdup(mem, s);
}
+
+/* For given LV find recursively the LV which holds lock for it */
+const struct logical_volume *lv_lock_holder(const struct logical_volume *lv)
+{
+ const struct seg_list *sl;
+
+ if (lv_is_cow(lv))
+ return lv_lock_holder(origin_from_cow(lv));
+
+ if (lv_is_thin_pool(lv))
+ /* Find any active LV from the pool */
+ dm_list_iterate_items(sl, &lv->segs_using_this_lv)
+ if (lv_is_active(sl->seg->lv)) {
+ log_debug("Thin volume \"%s\" is active.", sl->seg->lv->name);
+ return sl->seg->lv;
+ }
+
+ /* For other types, by default look for the first user */
+ dm_list_iterate_items(sl, &lv->segs_using_this_lv) {
+ /* FIXME: complete this exception list */
+ if (lv_is_thin_volume(lv) &&
+ lv_is_thin_volume(sl->seg->lv) &&
+ first_seg(lv)->pool_lv == sl->seg->pool_lv)
+ continue; /* Skip thin snaphost */
+ if (lv_is_external_origin(lv) &&
+ lv_is_thin_volume(sl->seg->lv))
+ continue; /* Skip external origin */
+ return lv_lock_holder(sl->seg->lv);
+ }
+
+ return lv;
+}
diff --git a/lib/metadata/lv.h b/lib/metadata/lv.h
index bac8bc2..ed0d745 100644
--- a/lib/metadata/lv.h
+++ b/lib/metadata/lv.h
@@ -90,4 +90,5 @@ const char *lv_layer(const struct logical_volume *lv);
int lv_active_change(struct cmd_context *cmd, struct logical_volume *lv,
activation_change_t activate);
char *lv_active_dup(struct dm_pool *mem, const struct logical_volume *lv);
+const struct logical_volume *lv_lock_holder(const struct logical_volume *lv);
#endif /* _LVM_LV_H */
Gitweb: http://git.fedorahosted.org/git/?p=lvm2.git;a=commitdiff;h=2ac217d408470dce…
Commit: 2ac217d408470dcecb69b83d9cbf7a254747fa5b
Parent: baf9ef2047675279c72f27abeb2c328f5de2c78d
Author: Peter Rajnoha <prajnoha(a)redhat.com>
AuthorDate: Fri May 3 13:20:07 2013 +0200
Committer: Peter Rajnoha <prajnoha(a)redhat.com>
CommitterDate: Fri May 3 13:55:53 2013 +0200
udev: fire pvscan --cache properly on CHANGE event for MD devices
Commit 756bcabbfe297688ba240a880bc2b55265ad33f0 restricted the
situations at which the LVM autoactivation fires - only on ADD
event for devices other than DM. However, this caused a problem
for MD devices...
MD devices are activated in a very similar way as DM devices:
the MD dev is created on first appeareance of MD array member
(ADD event) and stays *inactive* until the array is complete.
Just then the MD dev turns to active state and this is reported
to userspace by CHANGE event.
Unfortunately, we can't differentiate between the CHANGE event
coming from udev trigger/WATCH rule and CHANGE event coming from
the transition to active state - MD would need to add similar logic
we already use to detect this in DM world. For now, we just have
to enable pvscan --cache on *all* CHANGE events for MD so the
autoactivation of the LVM volumes on top of MD works.
A downside of this is that a spurious CHANGE event for MD dev
can cause the LVM volumes on top of it to be automatically activated.
However, one should not open/change the device underneath until
the device above in the stack is removed! So this situation should
only happen if one opens the MD dev for read-write by mistake
(and hence firing the CHANGE event because of the WATCH udev rule),
or if calling udev trigger manually for the MD dev.
(No WHATS_NEW here as this fixes the commit mentioned
above and which has not been released yet.)
---
udev/69-dm-lvm-metad.rules.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/udev/69-dm-lvm-metad.rules.in b/udev/69-dm-lvm-metad.rules.in
index 66c58b3..a0e48a1 100644
--- a/udev/69-dm-lvm-metad.rules.in
+++ b/udev/69-dm-lvm-metad.rules.in
@@ -21,6 +21,7 @@ SUBSYSTEM!="block", GOTO="lvm_end"
ENV{ID_FS_TYPE}!="LVM2_member|LVM1_member", GOTO="lvm_end"
ACTION=="remove", GOTO="lvm_scan"
+ACTION=="change", KERNEL=="md[0-9]*", GOTO="lvm_scan"
# If the PV is not a dm device, scan only after device addition (ADD event)
KERNEL!="dm-[0-9]*", ACTION!="add", GOTO="lvm_end"