archive mirror
 help / color / mirror / Atom feed
From: "Bryn M. Reeves" <>
To: LVM general discussion and development <>
Subject: Re: [linux-lvm] What is the use of thin snapshots if the external origin cannot be set to writable ?
Date: Mon, 23 Nov 2020 13:04:12 +0000	[thread overview]
Message-ID: <20201123130412.GB2229389@localhost.localdomain> (raw)
In-Reply-To: <>

On Sat, Nov 21, 2020 at 08:40:44AM +0530, Sreyan Chakravarty wrote:
> I am looking into thin snapshots since the older COW snapshots delay my
> boot enormously.
> My normal root fs is on a normal "non-thin" volume.
> So to make a snapshot I have boot into a live cd environment then set my
> root fs volume to read-only and then set it to inactive.

OK - I understand what's going on in your environment now, thanks!

Unfortunately it's not possible to have a writable external origin when
using device-mapper thin provisioned snapshots. To be able to write to
the origin while snapshots exist the origin device must also be a thin
provisioned logical volume.

This is explained in more detail in the kernel documentation for the
thin provisioning targets.


    External snapshots
    You can use an external **read only** device as an origin for a
    thinly-provisioned volume.  Any read to an unprovisioned area of the
    thin device will be passed through to the origin.  Writes trigger
    the allocation of new blocks as usual.
    One use case for this is VM hosts that want to run guests on
    thinly-provisioned volumes but have the base image on another device
    (possibly shared between many VMs).
    You must not write to the origin device if you use this technique!
    Of course, you may write to the thin device and take internal snapshots
    of the thin volume.

This allows a few niche use cases (like the VM example given), but it's
not the conventional way of using snapshots with thinp and it does
restrict what you can do.

This means that to use thinp snapshots most effectively you must set the
system up with a thin pool from the start (e.g. using the distro's
installer to set up the VG).

>             Command on LV vgfedora/fedora uses options that are invalid
> with LV parameters: lv_is_external_origin.

This is correct: currently you cannot make the origin writable since it
is an external snapshot.

There is some work going on at the moment that would make device-mapper
type features more flexible and available in other device types, but
with the features provided by current tools and the thinp kernel
support you need to use a thinp device for the snapshot origin too.
> Is there some sort of resolution ?

It means re-installing but if the system is set up to use a thin pool
and thin provisioned logical volumes from the start then you can use
snapshots without any of the limitations that you've bumped into with
external origin devices.


  parent reply	other threads:[~2020-11-23 13:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-21  3:10 [linux-lvm] What is the use of thin snapshots if the external origin cannot be set to writable ? Sreyan Chakravarty
2020-11-23 12:44 ` Gionatan Danti
2020-11-23 13:04 ` Bryn M. Reeves [this message]
2020-11-24 11:59   ` Sreyan Chakravarty
2020-11-25  8:46     ` Sreyan Chakravarty
2020-11-25 12:38     ` Bryn M. Reeves
2020-11-25 15:31       ` Sreyan Chakravarty

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201123130412.GB2229389@localhost.localdomain \ \ \

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