Re: [linux-lvm] Higher than expected metadata usage?

[Gionatan Danti <g.danti@assyoma.it>]

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