[linux-lvm] lvm limitations

[Tomas Dalebjörk]

just curious about this:

> Worth to note there is fixed strict limit of the ~16GiB maximum
> thin-pool kernel metadata size - which surely can be exhausted -
> mapping holds info about bTree mappings and sharing chunks between
> devices....
would that mean that one single thin-pool can maximum hold 16GiB/16 nr of blocks?

and how about if LVM2 uses VDO as backend, are there more limitations that I need to consider there that are not reflected here

Sent from my iPhone

> On 16 Sep 2020, at 00:26, Gionatan Danti <g.danti at assyoma.it> 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. - www.assyoma.it
> email: g.danti at assyoma.it - info at assyoma.it
> GPG public key ID: FF5F32A8