[linux-lvm] snapshot looses origin when other snapshot is merged to the same origin

[Zbigniew Kostrzewa]

Hi,

I have a question related to multiple snapshots of the same thin volume.
My scenario is that I create a thin pool, a thin volume and two
snapshots of that thin volume. Both snapshots have the thin volume set
as the origin volume. However, after I merge one of the snapshots to the
origin then the second snapshot looses information about the origin.

The question is if that is an expected behavior or if I am doing
something wrong? Is there a way to make the second snapshot keep having
the origin with merged first snapshot as its origin?

Regards,
Zbigniew Kostrzewa

[Chris Murphy]

On Fri, Sep 28, 2018 at 6:57 AM, Zbigniew Kostrzewa

Hi,
I have a question related to multiple snapshots of the same thin volume. My
scenario is that I create a thin pool, a thin volume and two snapshots of
that thin volume. Both snapshots have the thin volume set as the origin
volume. However, after I merge one of the snapshots to the origin then the
second snapshot looses information about the origin.
The question is if that is an expected behavior or if I am doing something
wrong? Is there a way to make the second snapshot keep having the origin
with merged first snapshot as its origin?

What file system are you using? And what lvm commands are you using
for all of this?

Someone else will have to answer the merging question, as it's not
something I've ever used or expect to use with thin volumes. Merging,
to me, sounds like a thick volume snapshots convention.

With thin volumes, each snapshot, even though it initially points to
an origin, is it's own completely independent volume. Given a thin
volume A, and snapshots created with 'lvcreate -s vg/A -n B' and
'lvcreate -s vg/A -n C' my experience is that A B C are initially
identical, and modifying A does not change B or C. Modifying B does
not change A or C. Modifying C does not change A or B.

By default, thin volume snapshots are not active volumes. So they're
not mountable. And once two or more are active, there's the potential
for confusion because you have literally two file systems that are
identical as far as the kernel is concerned. They have identical
volume UUIDs. I know XFS will refuse to mount a 2nd volume with the
same UUID as an already mounted file system; and while this can be
inhibited at mount time, I do not know the consequences.

[k***@9livesdata.com]

Post by Chris Murphy
On Fri, Sep 28, 2018 at 6:57 AM, Zbigniew Kostrzewa

Hi,
I have a question related to multiple snapshots of the same thin volume. My
scenario is that I create a thin pool, a thin volume and two snapshots of
that thin volume. Both snapshots have the thin volume set as the origin
volume. However, after I merge one of the snapshots to the origin then the
second snapshot looses information about the origin.
The question is if that is an expected behavior or if I am doing something
wrong? Is there a way to make the second snapshot keep having the origin
with merged first snapshot as its origin?

What file system are you using? And what lvm commands are you using
for all of this?
Someone else will have to answer the merging question, as it's not
something I've ever used or expect to use with thin volumes. Merging,
to me, sounds like a thick volume snapshots convention.
With thin volumes, each snapshot, even though it initially points to
an origin, is it's own completely independent volume. Given a thin
volume A, and snapshots created with 'lvcreate -s vg/A -n B' and
'lvcreate -s vg/A -n C' my experience is that A B C are initially
identical, and modifying A does not change B or C. Modifying B does
not change A or C. Modifying C does not change A or B.
By default, thin volume snapshots are not active volumes. So they're
not mountable. And once two or more are active, there's the potential
for confusion because you have literally two file systems that are
identical as far as the kernel is concerned. They have identical
volume UUIDs. I know XFS will refuse to mount a 2nd volume with the
same UUID as an already mounted file system; and while this can be
inhibited at mount time, I do not know the consequences.

Thanks for taking time to answer my question.

I don't do anything fancier than what is described in documentation for
creating thin volumes and snapshots of thinly provisioned volumes, i.e.:

lvcreate -L30G -T vg/root-pool
lvcreate -V20G -T vg/root-pool -n root
lvcreate --snapshot -n snap1 vg/root
lvcreate --snapshot -n snap2 vg/root
lvconvert --merge snap2

My use case is like so: I have a thinly provisioned root volume (with
rootfs on XFS). I create a snapshot after fresh installation. I install
some software. The I want to upgrade the software but in order to be
able to rollback the upgrade I create a second snapshot (before the
upgrade). When I do a rollback of the upgrade (lvconvert --merge snap2
&& reboot) I loose possibility to rollback to the first snapshot - taken
right after fresh installation. Most probably I can simply replace my
root volume with the first snapshot and probably I should get what I
want, that is rootfs after fresh installation, but running lvconvert
--merge is more convenient than replacing the origin with the snapshot
by myself.

Regards,
Zbigniew Kostrzewa

[Chris Murphy]

Post by k***@9livesdata.com

Post by Chris Murphy
On Fri, Sep 28, 2018 at 6:57 AM, Zbigniew Kostrzewa

Hi,
I have a question related to multiple snapshots of the same thin volume. My
scenario is that I create a thin pool, a thin volume and two snapshots of
that thin volume. Both snapshots have the thin volume set as the origin
volume. However, after I merge one of the snapshots to the origin then the
second snapshot looses information about the origin.
The question is if that is an expected behavior or if I am doing something
wrong? Is there a way to make the second snapshot keep having the origin
with merged first snapshot as its origin?

What file system are you using? And what lvm commands are you using
for all of this?
Someone else will have to answer the merging question, as it's not
something I've ever used or expect to use with thin volumes. Merging,
to me, sounds like a thick volume snapshots convention.
With thin volumes, each snapshot, even though it initially points to
an origin, is it's own completely independent volume. Given a thin
volume A, and snapshots created with 'lvcreate -s vg/A -n B' and
'lvcreate -s vg/A -n C' my experience is that A B C are initially
identical, and modifying A does not change B or C. Modifying B does
not change A or C. Modifying C does not change A or B.
By default, thin volume snapshots are not active volumes. So they're
not mountable. And once two or more are active, there's the potential
for confusion because you have literally two file systems that are
identical as far as the kernel is concerned. They have identical
volume UUIDs. I know XFS will refuse to mount a 2nd volume with the
same UUID as an already mounted file system; and while this can be
inhibited at mount time, I do not know the consequences.

Thanks for taking time to answer my question.
I don't do anything fancier than what is described in documentation for
lvcreate -L30G -T vg/root-pool
lvcreate -V20G -T vg/root-pool -n root
lvcreate --snapshot -n snap1 vg/root
lvcreate --snapshot -n snap2 vg/root
lvconvert --merge snap2

OK based on my reading of the documentation, my expectation of
'lvconvert --merge snap2' is effectively a shortcut for deleting root
and renaming snap2 to root. As a precondition, neither LV involved in
the merge can be open (they can't be mounted), if either are open, the
merge is delayed. But also I would not expect snap1 to be affected at
all by the merge.

I'm not sure if my "shortcut" understanding is correct though.

And honestly, I find the word "merge" in this context *really*
confusing. Because the common synonym for merge is combine, not revert
or rollback.

Post by k***@9livesdata.com
My use case is like so: I have a thinly provisioned root volume (with rootfs
on XFS). I create a snapshot after fresh installation. I install some
software. The I want to upgrade the software but in order to be able to
rollback the upgrade I create a second snapshot (before the upgrade). When I
do a rollback of the upgrade (lvconvert --merge snap2 && reboot) I loose
possibility to rollback to the first snapshot - taken right after fresh
installation. Most probably I can simply replace my root volume with the
first snapshot and probably I should get what I want, that is rootfs after
fresh installation, but running lvconvert --merge is more convenient than
replacing the origin with the snapshot by myself.

Understood.

I'll take a guess: the instant snap2 is "merged" or rather replaces
root, then that merged LV can no longer be an origin for snap1. It
stands entirely alone and that's why merge can't work with snap1 after
you've used merge on snap2.

I haven't done this myself, but you could dig into snapper which
supports both Btrfs and LVM thin for snapshotting and rollbacks, and
see what commands it's using and when for the LVM thin case for
rolling back.