On 27/03/2018 12:18, Zdenek Kabelac wrote:
Tool for size estimation is giving some 'rough' first guess/first choice
number.
The metadata usage is based in real-word data manipulation - so while
it's relatively easy to 'cup' a single thin LV metadata usage - once
there is a lot of sharing between many different volumes - the exact
size estimation
is difficult - as it depend on the order how the 'btree' has been
constructed.
I.e. it is surely true the i.e. defragmentation of thin-pool may give
you a more compact tree consuming less space - but the amount of work
needed to get thin-pool into the most optimal configuration doesn't pay
off. So you need to live with cases, where the metadata usage behaves
in a bit unpredictable manner - since it's more preferred speed over the
smallest consumed space - which could be very pricey in terms of CPU and
memory usage.
So as it has been said - metadata is 'accounted' in chunks for a
userspace app (like lvm2 is or what you get with 'dmsetup status') - but
how much free space is left in these individual chunks is kernel
internal...
Ok, understood.
It's time to move on, you address 7TB and you 'extremely' care about
couple MB 'hint here' - try to investigate how much space is wasted in
filesystem itself ;)
Mmm no, I am caring for the couple MBs themselves. I was concerned about
the possibility to get a full metadata device by writing far less data
than expected. But I now get the point.
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
