linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: Eric Toombs <ewtoombs@uwaterloo.ca>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] faster snapshot creation?
Date: Wed, 26 Feb 2020 11:01:26 +0100	[thread overview]
Message-ID: <a4708de8-93f9-e663-3184-099a8e40ac3c@redhat.com> (raw)
In-Reply-To: <bfd3824a-f360-b4ab-9a08-6a51c8c37a94@uwaterloo.ca>

Dne 25. 02. 20 v 22:35 Eric Toombs napsal(a):
> I tried thin pools and got the same snapshot creation time, about .45s.
> 

As it has been said - lvm2  is NOT only sending couple ioctl() to create snapshot.

Every lvm2 command essentially does a full system validation with respect to 
currently configured set of metadata - this exec-time  by faaaaaar exceeds
the actual snapshot creation time.
(Also snapshot monitoring is pretty 'time expensive' operation on its own)


> I also tried creating the entire vg in memory with losetup and that
> didn't change the creation time either.

lvm2 was never optimized towards 'hyper fast' manipulation with a single 
device - after all you are impacting your system resources in a major way - 
thus couple milliseconds here and there for majority of users doesn't really 
matter.

What is the most important in terms of speed is the 'minimal' delay which can 
be observed on origin being in use (aka 'suspend-resume' time-frame of origin 
takes short amount of time to block actual usage of the origin device - user 
should not see big latency...)

If you are aspiring of creating tens of snapshot per second - you probably 
have very unusual workflow/requirement and mostly likely lvm2 is not the right 
tool for such task ATM.

There used to exist 'slight' optimization where lvm2 executed as 'lvm shell' 
(so you basically stream lvm command though a pipe to such lvmshell) was 
'sharing' some cached content between runs of individual commands - but this 
was mostly lost and most likely would not squeeze a lot the time you refer.

So my advice - if you really need to use and create old snaps in very fast way 
is to developed your very own tool working in you restricted environment where 
you  might probably not care about meta/data consistencies, deal with speed of 
udev and gazillion other issues - you can run your small 'ioctl()' stream much 
more efficiently.

On the other hand it's well beyond my imagination what is good for 'very fast' 
creation of a snapshot when the overall performance of the system is then 
degraded by 50% or more...  but user can choice...


Zdenek

  reply	other threads:[~2020-02-26 10:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-22 11:58 Eric Toombs
2020-02-25  9:31 ` Gionatan Danti
2020-02-25  9:38 ` Zdenek Kabelac
2020-02-25 21:35   ` Eric Toombs
2020-02-26 10:01     ` Zdenek Kabelac [this message]
2020-02-26 14:03       ` Douglas Paul
2020-02-26  0:38 ` Stuart D. 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=a4708de8-93f9-e663-3184-099a8e40ac3c@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=ewtoombs@uwaterloo.ca \
    --cc=linux-lvm@redhat.com \
    --subject='Re: [linux-lvm] faster snapshot creation?' \
    /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

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