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@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
