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

Dne 15. 09. 20 v 23:24 Tomas Dalebjörk napsal(a):
> thanks
> ok, lets say that I have 10 LV on a server, and want create a thin lv snapshot every hour and keep that for 30 days
> that would be 24h * 30days * 10lv = 720 lv
> if I want to keep snapshot copies from more nodes, to serve a single repository of snapshot copies, than these would easily become several hundred thousands of lv
> not sure if this is a good idea, but I guess it can be very useful in some sense as block level incremental forever and instant recovery can be implemented for open sourced based applications
> what reflections do you have on this idea?


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.

You need to be aware that as soon as your volumes have some 'real-live'
you will soon need to keep many blocks in many 'different' copies which will
surely be reflected by the usage of the pool device itself - aka you will
most likely hit out-of-space sooner then you'll run out of devices.

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.

There is no practical way to change current LVM2 into a tool handling i.e. 
100.000 LV at decent speed - it's never been a target of this tool....



  parent reply	other threads:[~2020-09-15 21:47 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 [this message]
2020-09-15 22:26                 ` Gionatan Danti
2020-09-16  4:25                   ` Tomas Dalebjörk
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).