[linux-lvm] LVM generates wrong low_water_mark value in thin-pool's table

[M.H. Tsai]

Hi,

I found that the <low_water_mark> parameter of thin-pool's table might be
wrong. In kernel, the this parameter is the number of free blocks. However,
LVM commit 99237f0908d87592815f4bdf3c239e8a108e835c sets this value as the
number of USED blocks, according
to activation_thin_pool_autoextend_threshold_CFG. Is that a bug?


Thanks,
Ming-Hung Tsai

[Zdenek Kabelac]

Post by M.H. Tsai
Hi,
I found that the <low_water_mark> parameter of thin-pool's table might be
wrong. In kernel, the this parameter is the number of free blocks. However,
LVM commit 99237f0908d87592815f4bdf3c239e8a108e835c sets this value as the
number of USED blocks, according
to activation_thin_pool_autoextend_threshold_CFG. Is that a bug?

Ok - looks like my fault when translating lvm2 threshold usage to thin-pool
target threshold usage.

Thanks for noticing

Zdenek

[Zdenek Kabelac]

Post by M.H. Tsai
Hi,
I found that the <low_water_mark> parameter of thin-pool's table might be
wrong. In kernel, the this parameter is the number of free blocks. However,
LVM commit 99237f0908d87592815f4bdf3c239e8a108e835c sets this value as the
number of USED blocks, according
to activation_thin_pool_autoextend_threshold_CFG. Is that a bug?

Hi again


Yep bug on lvm2 size - fix has been upstreamed by this commit:

https://www.redhat.com/archives/lvm-devel/2016-February/msg00005.html


There is also some ongoing work on better lvresize support for more then 1
single LV. This will also implement better approach to resize of lvmetad which
is using different mechanism in kernel.

Lvm2 will try to follow the users wish but also be complaint with kernel
policy for free space in metadata device.

Regards

Zdenek