[linux-lvm] Higher than expected metadata usage?
Gionatan Danti
g.danti at assyoma.it
Tue Mar 27 10:58:40 UTC 2018
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 at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8
More information about the linux-lvm
mailing list