linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
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

  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).