[linux-lvm] lvm limitations

Gionatan Danti g.danti at assyoma.it
Tue Sep 1 13:21:34 UTC 2020


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