Unable to parse free thin sizes error on Satellite - inside of piraeus linstor-satellite

[danoh]

Hello

Since the original issue is closed, I'm opening a new one.

For details please check the https://github.com/LINBIT/linstor-server/issues/80

I'm encountering the same issue on a fresh Debian 12 installation. The "percent" column is missing for all newly created thin volumes that haven't had any logical volumes created yet. Rebooting doesn't resolve the problem. In fact, whenever I create a new thin pool without any logical volumes, the lvm2 utilities don't display the "percent" column at all.

This issue can be addressed using the --reportformat json flag. In this case, the column is populated with zeros.

Installing the thin-provisioning-tools package doesn't seem to help in this specific scenario.

[ghernadi]

Hello,

I just tested what you said, but it worked for me as expected. A fresh Debian 12, installed lvm2 (which automatically pulled in thin-provisioning-tools, created PV, VG and finally the thin-pool itself. The data_percent column was there (although showing 0.00, which is quite expected), creating a thin volume also worked and writing to that volume increased the data_percent of both, the thin-volume and the thin-pool.

Edit: Can you show me your exact output of lvs, vgs as well as vgs -o lv_name,lv_size,data_percent --units b --separator ";" --noheadings --nosuffix

Let me know if you find some difference in your setup

root@deb-test1:~# pvs
root@deb-test1:~# vgs
root@deb-test1:~# lvs
root@deb-test1:~# pvcreate /dev/vdb 
  Physical volume "/dev/vdb" successfully created.
root@deb-test1:~# vgcreate scratch /dev/vdb
  Volume group "scratch" successfully created
root@deb-test1:~# lvcreate --size 1G -T -n scratch/thin
  Thin pool volume with chunk size 64.00 KiB can address at most <15.88 TiB of data.
  Logical volume "thin" created.
root@deb-test1:~# vgs
  VG      #PV #LV #SN Attr   VSize  VFree   
  scratch   1   1   0 wz--n- <2.00g 1012.00m
root@deb-test1:~# vgs -o lv_name,lv_size,data_percent --units b --separator  ";" --noheadings --nosuffix 
  thin;1073741824;0.00
root@deb-test1:~# lvs
  LV   VG      Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  thin scratch twi-a-tz-- 1.00g             0.00   10.94                           
root@deb-test1:~# lvcreate --virtualsize 104m scratch --thinpool thin --name test_vlm
  Logical volume "test_vlm" created.
root@deb-test1:~# lvs
  LV       VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  test_vlm scratch Vwi-a-tz-- 104.00m thin        0.00                                   
  thin     scratch twi-aotz--   1.00g             0.00   11.04                           
root@deb-test1:~# dd if=/dev/urandom of=/dev/scratch/test_vlm bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.141203 s, 74.3 MB/s
root@deb-test1:~# lvs
  LV       VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  test_vlm scratch Vwi-a-tz-- 104.00m thin        9.62                                   
  thin     scratch twi-aotz--   1.00g             0.98   11.04                           
root@deb-test1:~# cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@deb-test1:~# 

[danoh]

Hello, I figured out how this can happen:

lvs
  LV   VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  thin scratch twi---tz-- <14.00g 

lvchange -ay /dev/scratch/thin

lvs
  LV   VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  thin scratch twi-aotz-- <14.00g             0.00   0.79

lvchange -an /dev/scratch/thin

lvs
  LV   VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  thin scratch twi---tz-- <14.00g

interesting is, that you won't be able to see any problem, even deactivated thin pool can create new subvolumes.

lvcreate -n test1 -V 1G  --thin scratch/thin
  Logical volume "test1" created.

lvs
  LV    VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  test1 scratch Vwi-a-tz--   1.00g thin        0.00                                   
  thin  scratch twi---tz-- <14.00g             0.00   0.79

and if there is some thin volume present, even deactivated this pool shows the percent column. So the server can run forever with deactivated thin pools.

I am now a little bit confused. But I still think, that the parsing algorithm should work even if the percent is missing == thin is deactivated.