[linux-lvm] [RFC, 2nd try] Let udev play with snapshots

[Jan Blunck]

On Wed, Oct 11, Jan Blunck wrote:

> - creating "vg-snapshot"
> - clearing the start of "vg-snapshot"
> - removing "vg-snapshot"                                                  (1)

Actually this must be deactivation of vg-snapshot. This is where the
deactivation code complains about the usage count of the LV.

> - creating "vg-origin-real"
> - creating "vg-snapshot-cow"
> - creating "vg-snapshot"
> - suspending "vg-origin" and "vg-origin-real"
> - reload tables
> - resuming "vg-origin-real", "vg-snapshot-cow", "vg-snapshot" and         (2)
>   "vg-origin"

I looked into the lvcreate code and realised that the deactivation code is
only complaining about the usage count because "vg-snapshot" is marked
VISIBLE_LV. Since the LV is at that moment used for clearing I think it should
be marked internal.

I know that this isn't a perfect solution yet. In the long term we need to give
udev a change to determine if an LV is internal or not (e.g. by reading the
VISIBLE_LV status).

BTW: Why do we actually create links even if the LV is marked invisible? Does
that make any sense at all?

RFC,
	Jan
---
Index: LVM2/tools/lvcreate.c
===================================================================
--- LVM2.orig/tools/lvcreate.c
+++ LVM2/tools/lvcreate.c
@@ -694,6 +694,10 @@ static int _lvcreate(struct cmd_context 
 		}
 	}
 
+	/* We are cleaning the exception table first, so let it be internal */
+	if (lp->snapshot)
+		status &= ~VISIBLE_LV;
+
 	if (!(lv = lv_create_empty(vg->fid, lv_name ? lv_name : "lvol%d", NULL,
 				   status, lp->alloc, 0, vg))) {
 		stack;
@@ -792,6 +796,9 @@ static int _lvcreate(struct cmd_context 
 			return 0;
 		}
 
+		/* we are no longer an internal LV */
+		lv->status |= VISIBLE_LV;
+
 		if (!vg_add_snapshot(vg->fid, NULL, org, lv, NULL,
 				     org->le_count, lp->chunk_size)) {
 			log_err("Couldn't create snapshot.");