[linux-lvm] lvm limitations

Tomas Dalebjörk tomas.dalebjork at gmail.com
Tue Sep 15 19:16:08 UTC 2020


thanks for the feedback 

in previous older versions of LVM, I guess that each lv requires a minor, major and these are might have limitations of how many can be addressed 

but how about LVM2?

if I intend to have many hundred thousands of LV, would that be any issue?

Sent from my iPhone

> On 1 Sep 2020, at 15:21, Gionatan Danti <g.danti at assyoma.it> wrote:
> 
> Il 2020-08-30 21:30 Zdenek Kabelac ha scritto:
>> Hi
>> Lvm2 has only ascii metadata (so basically what is stored in
>> /etc/lvm/archive is the same as in PV header metadata area -
>> just without spaces and some comments)
>> And while this is great for manual recovery, it's not
>> very efficient in storing larger number of LVs - there basically
>> some sort of DB attemp would likely be needed.
>> So far however there was no real worthy use case - so safety
>> for recovery scenarios wins ATM.
> 
> Yes, I agree.
> 
>> Thin - just like any other LV takes some 'space' - so if you want
>> to go with higher amount - you need to specify bigger metadata areas
>> to be able to store such large lvm2 metadata.
>> There is probably not a big issue with lots of thin LVs in thin-pool as long
>> as user doesn't need to have them active at the same time. Due to a nature of
>> kernel metadata handling, the larger amount of active thin LVs from
>> the same thin-pool v1 may start to compete for the locking when
>> allocating thin pool chunks thus killing performance - so here is
>> rather better to stay in some 'tens' of actively provisioning thin
>> volumes when the 'performance' is factor.
> 
> Interesting.
> 
>> 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....
> 
> Yes, I know about this specific limitation.
> 
> Thanks.
> 
> -- 
> 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





More information about the linux-lvm mailing list