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
prev parent 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.