[linux-lvm] [RFC] Let udev play with snapshots

[linux-lvm] [RFC] Let udev play with snapshots

[Jan Blunck]

Hi,

it seems that the snapshot problem isn't solved completely by our latest
changes. I looked into it and found something:

The problem is that udev isn't able to differentiate between dm targets that
aren't supposed to be opened by anything else than the lvm2 tools itself or
not. When we are creating a snapshot, this is what we do:

- creating "vg-snapshot"
- clearing the start of "vg-snapshot"
- removing "vg-snapshot"                                                  (1)
- 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"

At the point (1) udev already run vol_id on vg-snapshot. This LV is only
created to clear the exception store of the snapshot to be created. So
lvcreate tries to remove the still open vg-snapshot.

What we need to do is to tell udev that it shouldn't open the intermediate
vg-snapshot target but wait until (2) to open it.

I'm not quite certain about how to do this. IIRC Heinz told me during the
summit about the tagging possibilities. The problem is that tags are not
supported by snapshots but as the first LV isn't a snapshot ... So I propose
the tagging of all kind of intermediate LVs so that udev can easily
differentiate by calling "dmsetup lstag" (or maybe lsattr ;)

Comments?

Re: [linux-lvm] [RFC] Let udev play with snapshots

[Alasdair G Kergon]

We discussed this at OLS and decided that lvm2 would wait
for udev to finish whatever it wanted to do before writing
to the cow.  A yet-to-be-specified signalling mechanism would be 
introduced to achieve this.

Alasdair
-- 
agk@redhat.com

Re: [linux-lvm] [RFC] Let udev play with snapshots

[Jan Blunck]

On Wed, Oct 11, Alasdair G Kergon wrote:

> We discussed this at OLS and decided that lvm2 would wait
> for udev to finish whatever it wanted to do before writing
> to the cow.  A yet-to-be-specified signalling mechanism would be 
> introduced to achieve this.

Yeah, I forgot to mention that what I propose is what Kay and me came up
with.

It isn't the cow that makes problems here. It is the first LV that we use for
cleaning. AFAIK this is a linear table. IMHO we don't need another signalling
mechanism but a sane way how udev can tell if there every will be a filesystem
in the LV that was just created.

At the moment udev is skipping over all LV with "*snapshot*" or "*error*"
mentioned in the table:

 PROGRAM!="/sbin/dmsetup status -j %M -m %m", GOTO="device_mapper_end"
 RESULT=="|*snapshot*|*error*", GOTO="device_mapper_end"

I think we should extend this by giving udev a way how it could tell if it
should try to do something with the device.

Re: [linux-lvm] [RFC] Let udev play with snapshots

[Alasdair G Kergon]

The cow begins life as a real LV.
There is no way to distinguish it from other LVs.

Changing that means changing the "create a snapshot" process into a single
LVM2 metadata transaction (or a pair of related transactions).  Currently it's
two independent transactions - creating a new, empty LV; creating a snapshot
using that LV.  Doing that would allow us to back out the change properly if
it's aborted too.

Alasdair
-- 
agk@redhat.com

Re: [linux-lvm] [RFC] Let udev play with snapshots

[Jan Blunck]

On Wed, Oct 11, Alasdair G Kergon wrote:

> The cow begins life as a real LV.
> There is no way to distinguish it from other LVs.
> 
> Changing that means changing the "create a snapshot" process into a single
> LVM2 metadata transaction (or a pair of related transactions).  Currently it's
> two independent transactions - creating a new, empty LV; creating a snapshot
> using that LV.  Doing that would allow us to back out the change properly if
> it's aborted too.

Yes, that is probably the right thing to do.

But I still need a solution for todays code. When we are clearing the
exception store we know that the LV is going to be removed soon (and that udev
will never find a valid filesystem in it). So why don't we tell udev that it
shouldn't look at it in the first place.

The easiest thing that we came up with is to mark the thing somehow. So we
either use a different naming scheme for that LV (I don't like that idea) or
we use a tag if possible.

[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.");

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

[Alasdair G Kergon]

On Mon, Oct 23, 2006 at 03:41:00PM +0200, Jan Blunck wrote:
> On Wed, Oct 11, Jan Blunck wrote:
> > - 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.
 
The step will fail if it's still open by the time the kernel tries
to remove it.

As discussed on irc, let's try to optimise out the deactivate/activate.
 (a) activate cow excl local invisible (overriding 'visible' in metadata) ?
 (b) initialise zeros
 (c) ensure dev_flush() ran
 (d) skip the deactivate step
 ...

Alasdair
-- 
agk@redhat.com

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

[Alasdair G Kergon]

On Tue, Oct 24, 2006 at 07:21:58PM +0100, Alasdair G Kergon wrote:
> As discussed on irc, let's try to optimise out the deactivate/activate.

I've checked in an attempt to do this: it turns out that the current
structure of the code allows the simplest approach (skipping the cow
deactivate) to work regardless of whether or not options like --persistent
or --permission are supplied.  The 'snapshot' LV mapped device gets created
with the correct properties for the snapshot, but pointing to the cow and it
gets zeroed.  Then the cow is activated in a new mapped device and the old
one gets reused for the proper snapshot.

Alasdair
-- 
agk@redhat.com