All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: "Alexander E. Patrakov" <patrakov@gmail.com>,
	"LVM general discussion and development" <linux-lvm@redhat.com>,
	"Георгий Бажуков" <g.bazhukov@ideco.ru>
Subject: Re: [linux-lvm] LVM and chain of snapshots
Date: Wed, 20 Jan 2016 14:11:55 +0100	[thread overview]
Message-ID: <569F879B.8070401@redhat.com> (raw)
In-Reply-To: <569F854C.5070404@gmail.com>

Dne 20.1.2016 v 14:02 Alexander E. Patrakov napsal(a):
> 20.01.2016 17:09, Zdenek Kabelac wrote:
>> Using lots of old-snaphosts is very bad plan - really time to look at
>> thin-provisioning....
>> Old-snaps are not going to scale.....
>
> Well, I have already tried using lots of thin snapshots on my PC, in a context
> different from what Mark wants. Namely, my snapshots were created by Snapper,
> hourly.
>
> Thin snapshots may indeed scale well for reads and writes, but currently they
> don't scale at all for the initial activation. The problem is that "vgchange
> -ay" and "vgchange -an", by default, run "thin_check", and the more snapshots
> I have, the more it takes for "thin_check" to finish. With 1 snapshot, it is
> quick enough so that I don't notice. But with, say, 200 snapshots (some of
> which include creation of an iso image), it takes more than 1.5 minutes - more
> than the initramfs (or myself) is going to wait during the boot process.

Well the execution of thin_check is 'rather' security feature.
It's been added to capture possible errors of kernel driver.
I guess now we are possibly in the age where deep checking might no longer be 
necessary.

So if you feel the time spend on thin_checking doesn't pay-off - you can try 
to add option   '--skip-mappings'  (see lvm.conf field  global/thin_check_options)

Also  you really should not keep 200 snapshots if you don't need them.
So probably try to maintain your snapshots better (drop unneeded ones...)

And final note - I do not believe activation of multi-gigabyte old-snapshot is 
going to give you any better results - since reading of old metadata is 
actually much slower then management of thin-pool & thin_check - just try it....

It's fairly naive to expect old-snaps will do any better job when we are 
talking about 200 snaps.

Also there is no support for snaps of snaps of snaps with old-snapshot,
so it's not even comparable....

Regards

Zdenek

      reply	other threads:[~2016-01-20 13:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20 10:37 [linux-lvm] LVM and chain of snapshots Марк Коренберг
2016-01-20 12:09 ` Zdenek Kabelac
2016-01-20 12:54   ` Марк Коренберг
2016-01-20 14:20     ` Zdenek Kabelac
2016-01-20 13:02   ` Alexander E. Patrakov
2016-01-20 13:11     ` Zdenek Kabelac [this message]

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=569F879B.8070401@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=g.bazhukov@ideco.ru \
    --cc=linux-lvm@redhat.com \
    --cc=patrakov@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.