archive mirror
 help / color / mirror / Atom feed
From: "Tomas Dalebjörk" <>
To: Gionatan Danti <>
Cc: LVM general discussion and development <>,
	Zdenek Kabelac <>
Subject: Re: [linux-lvm] lvm limitations
Date: Wed, 16 Sep 2020 06:25:21 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

thanks for all the good reflections

the intention is to see if backups can be done in a much more easy way than have ever been built before

commercial hardware based snapshots limits the amount of snapshots to 256 per filesystem forcing operators to select this only for short living retentions
some have even fewer than that

another solution could be to store the lv as file into a larger fs, and snapshot these fs that than works as a group; just to decrease the amount of lv needed by the repository host. possible to do this, but will make the retention management more complex.
and especially if operators want to change retention for a given snapshot, as retention only can be the same for everything stored on the same lv.
that would require a move of the ‘base’ lv file into a separate lv, unless there is a way to rebuild vdo dedup data without a move of the block to represent the file/lv object elsewhere.
like clone of a lv...

perhaps a snapshot of the origin can be a new master? if that is ok, which I think is ok, than that will work without a move


Sent from my iPhone

> On 16 Sep 2020, at 00:26, Gionatan Danti <> wrote:
> Il 2020-09-15 23:47 Zdenek Kabelac ha scritto:
>> You likely don't need such amount of 'snapshots' and you will need to
>> implement something to remove snapshot without need, so i.e. after a
>> day you will keep maybe 'every-4-hour' and after couple days maybe
>> only a day-level snapshot. After a month per-week and so one.
> Agree. "Snapshot-thinning" is an essential part of snapshot management.
>> Speaking of thin volumes - there can be at most 2^24 thin devices
>> (this is hard limit you've ask for ;)) - but you have only  ~16GiB of
>> metadata to store all of them - which gives you ~1KiB of data per such
>> volume -
>> quite frankly this is not too much  - unless as said - your volumes
>> are not changed at all - but then why you would be building all this...
>> That all said -  if you really need that intensive amount of snapshoting,
>> lvm2 is likely not for you - and you will need to build something on your own,
>> as you will need way more efficient and 'targeted' solution for your purpose.
> Thinvols are not activated by default - this means it should be not a big problem managing some hundreds of them, as the OP ask. Or am I missing something?
> Regards.
> -- 
> Danti Gionatan
> Supporto Tecnico
> Assyoma S.r.l. -
> email: -
> GPG public key ID: FF5F32A8

  reply	other threads:[~2020-09-16  4:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-29 23:25 [linux-lvm] lvm limitations Tomas Dalebjörk
2020-08-30 17:33 ` Zdenek Kabelac
2020-08-30 18:01   ` Gionatan Danti
2020-08-30 19:30     ` Zdenek Kabelac
2020-09-01 13:21       ` Gionatan Danti
2020-09-15 19:16         ` Tomas Dalebjörk
2020-09-15 20:08           ` Zdenek Kabelac
2020-09-15 21:24             ` Tomas Dalebjörk
2020-09-15 21:30               ` Stuart D Gathman
2020-09-15 22:24                 ` Gionatan Danti
2020-09-15 21:47               ` Zdenek Kabelac
2020-09-15 22:26                 ` Gionatan Danti
2020-09-16  4:25                   ` Tomas Dalebjörk [this message]
2020-09-17 19:24                     ` Zdenek Kabelac
2020-09-16  4:31                   ` Tomas Dalebjörk
2020-09-16  4:58                   ` Tomas Dalebjörk
2020-09-17 19:17                     ` Zdenek Kabelac
2020-09-17 19:32                   ` Zdenek Kabelac
2020-09-14  6:03 Tomas Dalebjörk

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 \ \ \ \ \ \

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