From: kostrzewa@9livesdata.com
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Chris Murphy <lists@colorremedies.com>
Subject: Re: [linux-lvm] snapshot looses origin when other snapshot is merged to the same origin
Date: Fri, 28 Sep 2018 20:41:08 +0200 [thread overview]
Message-ID: <130649f9bd1cc2378d3bee1fd2121d39@9livesdata.com> (raw)
In-Reply-To: <CAJCQCtS1B088K1k=SLTbs34+nfD_PZWF738VROZyyb9EYX1h1A@mail.gmail.com>
On 28.09.2018 18:59, Chris Murphy wrote:
> On Fri, Sep 28, 2018 at 6:57 AM, Zbigniew Kostrzewa
> <kostrzewa@9livesdata.com> wrote:
>> 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
next prev parent reply other threads:[~2018-09-28 18:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-28 12:57 [linux-lvm] snapshot looses origin when other snapshot is merged to the same origin Zbigniew Kostrzewa
2018-09-28 16:59 ` Chris Murphy
2018-09-28 18:41 ` kostrzewa [this message]
2018-09-28 19:47 ` Chris Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=130649f9bd1cc2378d3bee1fd2121d39@9livesdata.com \
--to=kostrzewa@9livesdata.com \
--cc=linux-lvm@redhat.com \
--cc=lists@colorremedies.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).