Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
danoh opened this issue Mar 6, 2024 · 2 comments

Comments

@danoh
Copy link

danoh commented Mar 6, 2024

Hello

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

For details please check the #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
Copy link
Contributor

ghernadi commented Mar 6, 2024

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
Copy link
Author

danoh commented Apr 25, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants