From: Mike Snitzer <snitzer@redhat.com>
To: Francois Blondel <fblondel@intelliad.de>
Cc: "linux-lvm@redhat.com" <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM snapshot: in memory COW table
Date: Wed, 25 Jan 2017 09:38:25 -0500 [thread overview]
Message-ID: <20170125143825.GC15251@redhat.com> (raw)
In-Reply-To: <1485351995.3931.4.camel@intelliad.de>
On Wed, Jan 25 2017 at 8:46am -0500,
Francois Blondel <fblondel@intelliad.de> wrote:
> Hi all,
>
> We currently use LVM snapshot as a solution to backups block devices.
> The snapshot is not active for a long time, only for the time during
> which we need to upload the backup to the backup server.
>
> As I could read, for example here: http://www.nikhef.nl/~dennisvd/lvmcrap.html
> snapshots multiply the IO needs of the origin Logical Volume.
> We would like to avoid that.
The old dm-snapshot target has "transient" snapshot store already.
See drivers/md/dm-snap-transient.c
Use of transient isn't going to change the fact that you'll still need N
snapshot stores; and that any write will trigger an N-way copy-out
penality when N snapshots of the origin exist. All you'd be doing with
transient is getting implicit improved performance of memory speeds.
For improved scalability you'd do well to switch to using DM
thin-provisioning's snapshots. There are some customers/users who are
already making use of it for the backend for backups (using thin_delta
to know what the differences are between thin volumes and snapshots).
> As our servers have enough free RAM, and the COW table of the
> snapshot remains quite small, I had the project to store the snapshot
> (or its cow table) in RAM.
> The goal there is to avoid additional IO aimed at the disk and redirect
> them to memory.
> Yes, this would lead to the loss of the snapshot in case of power
> failure, but this is not an issue for our use case.
Documentation/device-mapper/snapshot touches on "transient" with:
*) snapshot <origin> <COW device> <persistent?> <chunksize>
A snapshot of the <origin> block device is created. Changed chunks of
<chunksize> sectors will be stored on the <COW device>. Writes will
only go to the <COW device>. Reads will come from the <COW device> or
from <origin> for unchanged data. <COW device> will often be
smaller than the origin and if it fills up the snapshot will become
useless and be disabled, returning errors. So it is important to monitor
the amount of free space and expand the <COW device> before it fills up.
<persistent?> is P (Persistent) or N (Not persistent - will not survive
after reboot). O (Overflow) can be added as a persistent store option
to allow userspace to advertise its support for seeing "Overflow" in the
snapshot status. So supported store types are "P", "PO" and "N".
The difference between persistent and transient is with transient
snapshots less metadata must be saved on disk - they can be kept in
memory by the kernel.
next prev parent reply other threads:[~2017-01-25 14:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 13:46 [linux-lvm] LVM snapshot: in memory COW table Francois Blondel
2017-01-25 14:38 ` Mike Snitzer [this message]
2017-01-26 0:50 ` Stuart Gathman
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=20170125143825.GC15251@redhat.com \
--to=snitzer@redhat.com \
--cc=fblondel@intelliad.de \
--cc=linux-lvm@redhat.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).