LINUX.ORG.RU
Форум — Linux-hardware  

LVM, Proxmox, NVME LV read only. Че делать

 , ,


1

2

Столкнулся с проблемой что в одной из виртуальных машин посыпались ошибки дисковых операций типа:

[  +0.000006] EXT4-fs error (device dm-6): kmmpd:179: comm kmmpd-dm-6: Error wri                                                                                                                                                             ting to MMP block
[  +0.000006] blk_update_request: I/O error, dev nvme0n1, sector 57003600 op 0x1                                                                                                                                                             :(WRITE) flags 0x8800 phys_seg 1 prio class 2
[  +0.000006] EXT4-fs warning (device dm-6): ext4_end_bio:342: I/O error 10 writ

первая мысль умер винт…но dmesg хоста ничего не говорил об ошибках в своих сообщениях. Похоже проблема моя описана тут: https://bugzilla.proxmox.com/show_bug.cgi?id=3738 , но решения из этого топика не решили проблему. Сейчас при попытке создать VM получаю ошибки:

 WARNING: Thin pool Gigabyte_nvme/Gigabyte_nvme needs check has read-only metadata.
  WARNING: Thin pool Gigabyte_nvme/Gigabyte_nvme has unexpected transaction id 18, expecting 19.
no lock found trying to remove 'create'  lock
error before or during data restore, some or all disks were not completely restored. VM 100 state is NOT cleaned up.

WARNING: Thin pool Gigabyte_nvme/Gigabyte_nvme needs check has read-only metadata. Сам же этот том находится в режиме только чтение:

 --- Logical volume ---
  LV Name                Gigabyte_nvme
  VG Name                Gigabyte_nvme
  LV UUID                Rg53rQ-MrG1-o1UF-c7UJ-VwOd-lcU1-mecQ40
  LV Write Access        read/write (activated read only)
  LV Creation host, time pve, 2023-03-09 11:22:50 +0300
  LV Pool metadata       Gigabyte_nvme_tmeta
  LV Pool data           Gigabyte_nvme_tdata
  LV Status              available
  # open                 0
  LV Size                493.39 GiB
  Allocated pool data    9.56%
  Allocated metadata     0.82%
  Current LE             126308
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     512
  Block device           253:5

утилита проверки выдает такое:


thin_check /dev/Gigabyte_nvme/Gigabyte_nvme_meta0
examining superblock
TRANSACTION_ID=18
METADATA_FREE_BLOCKS=1250303
examining devices tree
examining mapping tree
  thin device 2 is missing mappings [1699316, 1699444]
    bad checksum in btree node (block 9276)

Куда дальше копать то? может вообще по неправильному пути иду?



Последнее исправление: pistoletov (всего исправлений: 1)

LVM thin pool прекращает работать, когда на нём кончается место.

Дальше есть 2 пути:

  1. изучаете lvm thin pool (в т.ч. подводные камни, устраняете проблемы и используете его.
  2. переходите на lvm (не thin) или zfs.

В любом случае, я бы сначала загрузился с LiveCD/LiveUSB и сделал бы полный бэкап (dd if=/dev/nvme0n1 of=/mnt/external-usb/nvme0n1.img bs=1M status=progress), а потом бы уже занимался «ремонтом» или «переходом».

Harliff ★★★★★
()
Последнее исправление: Harliff (всего исправлений: 1)

Похоже проблема моя описана тут: https://bugzilla.proxmox.com/show_bug.cgi?id=3738 , но решения из этого топика не решили проблему.

У Вас нет ничего proxmox-специфического, это дефолтное поведение . LVM Thin pool.

Соответственно, можете нагуглить любые решения по запросам типа «lvm thin pool repair» и использовать их. После того, как сделаете бэкап (если, конечно, данные имеют ценность).

UPD: рекомендую начать с man 7 lvmthin (там есть раздел «Metadata check and repair»)

Harliff ★★★★★
()
Последнее исправление: Harliff (всего исправлений: 1)
Ответ на: комментарий от Harliff

Спасибо за ответ. LVM thin pool прекращает работать, когда на нём кончается место.

Это единственный вариант? На всех дисках места хватает с головой.. Бекапы виртуальных машин есть так что если в результате экспериментов что-то пойдет не так создам заново storage.


 lvchange -an Gigabyte_nvme/Gigabyte_nvme
 lvconvert --repair Gigabyte_nvme/Gigabyte_nvme
  Active pools cannot be repaired.  Use lvchange -an first.

что тут не так? или это можно делать только загрузившись с live? Система у меня на другом физическом диске.

pistoletov
() автор топика

Короче, не стал заморачиваться с восстановлением. Прибил все и создал по новой из бекапов. На порядок быстрее чем разбираться с repair. Слышал рекомендации немного места добавить разделу метаданных. Стоит ли?

pistoletov
() автор топика
Ответ на: комментарий от pistoletov

Скорость такая же, разница в нормальных снапшотах и возможности в тонких томах выделять больше места, чем есть. Последнее сложно назвать плюсом. А «медленных» снапшотов обычных томов вполне достаточно для целей резервного копирования.

anonymous
()
Ответ на: комментарий от anonymous

можно создать в этой же vg lv типа lvm и потом move vm сделать в новый lvm хранилище?

и еще вопросец можно? к vm добавлено хранилище типа directory Размером 180гиг.

scsi1: backup:100/vm-100-disk-0.qcow2,backup=0,size=180G

Но сам физический файл занимает 311гиг. Не дофига ли? может его как-то ресайз сделать нужно?

-rw-r----- 1 root root 311G Dec 25 18:10 vm-100-disk-0.qcow2
pistoletov
() автор топика
Ответ на: комментарий от pistoletov

можно создать в этой же vg lv типа lvm и потом move vm сделать в новый lvm хранилище?

Технически можно, это даже нормально, но в Proxmox я бы не стал. Проверять не буду, но там вроде даже стандартные фильтры для утилит LVM могут затруднить жизнь с такими конфигурациями. Но если есть желание и возможность экспериментировать, то почему нет.

Не дофига ли? может его как-то ресайз сделать нужно?

Не подскажу ничего конкретного. Если такое поведение не описано в документации Proxmox, то почитай man qemu-img (это в целом полезно, если имеешь дело с виртуализацией).

anonymous
()
Ответ на: комментарий от Aceler

Есть внутри снапшот но 0 размера…хм..тогда откуда эти 130 гиг лишних то..

:/mnt/raid/backup/images/100# qemu-img info *.qcow2
image: vm-100-disk-0.qcow2
file format: qcow2
virtual size: 180 GiB (193273528320 bytes)
disk size: 310 GiB
cluster_size: 65536
Snapshot list:
ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
1         bad_blocks            0 B 2023-03-07 00:50:20 00:50:03.672
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
pistoletov
() автор топика
Ответ на: комментарий от pistoletov

откуда эти 130 гиг лишних то…

Могу ошибаться; кажется, так thin provisoing работает.

Например,

  • Вы выделили для VM раздел 100 Гб. С точки зрения ОС в VM - это обычный диск. С точки зрения хоста - это «тонкий» раздел.
  • ОС в VM стала работать и генерить дисковую активность - создавать файлы, записывать в них информацию, перезаписывать файлы, перезаписывать части файлов, удалять файлы и создавать новые и т.д. - короче, работать как обычно.
  • работая так, VM сгенерировала операций дисковой записи на 300 Гб. При этом, если зайти в ОС то там видно, что, например, из имеющихся 100 Гб у неё есть 30 Гб свободных.
  • в итоге, у вас фактически занято 300 Гб (в cow файле или в VG). Да, всё правильно - 100 Гб диск виртуалки смог занять втрое больше своего объема на хосте.
  • если зайти в VM и удалить там, например, 40 Гб файлов, то на хосте по-прежнему будет занято 300 Гб.

Что с этим делать?

  • делать TRIM внутри VM - то есть, уведомлять блочное устройство о том, что часть блоков ей больше не используются. Тут есть нюансы (раньше было так: где-то trim работает, где-то нет, где-то нужны особые настройки и драйверы; как сейчас - не знаю). Насколько я знаю, TRIM надо настраивать заранее; то есть, в Вашем случае проще подключить второй диск в VM и сделать копирование через dd/tar/rsync в виртуалке (или через qemu-img в хосте).
  • использовать thin provisioning там, где оно нужно - то есть там, где есть короткий цикл «создали много копий существующего блочного устройства, что-то поделали, удалили все копии» (в компьютерных классах, при тестировании ПО и т.д.) и не использовать там, где оно не нужно (в ситуации, когда создали виртуалку, индивидуально её настроили с нуля и используете в течение долгого времени).
Harliff ★★★★★
()
Последнее исправление: Harliff (всего исправлений: 2)
Ответ на: комментарий от Harliff

Ну глядите это просто примонтированный диск как directory находящийся на зеркальном raid. LVM тут даже не использую. ВЫделил виртуальной машине из этого хранилища часть ресурсов.Правда discard не был включен. Попробую с включенным дискард посмотреть изменится ли размер файла. Раньше это хранилище было указано как место хранения снапшотов но снапшоты удалил и сейчас их не делаю. Имеет ли отношение технологии thin provisoing к типам хранилища directory?

pistoletov
() автор топика
Ответ на: комментарий от pistoletov

Имеет ли отношение технологии thin provisoing к типам хранилища directory

Имеет. У Вас в direcory лежит файл .qcow2, который работает в режиме thin provisioning.

Вообще, для qcow2 можно использовать -o preallocation=full, в т. ч. и в Proxmox (у хранилища directory есть опция «preallocation» — её можно выставить в full, но повлияет это только на вновь создаваемые файлы).

Harliff ★★★★★
()
Ответ на: комментарий от pistoletov

Попробую с включенным дискард посмотреть изменится ли размер файла.

Если эта тема интересна, то можете экспериментировать. В помощь man qemu-img, документация proxmox и форум proxmox, где разбираются нюансы.

Harliff ★★★★★
()
Ответ на: комментарий от Harliff

Спасибо за советы. Появилось время на эксперименты и смог уменьшить размер qcow2 файла, способ довольно долгий но рабочий

qemu-img convert -c -O qcow2 /mnt/raid/backup/images/100/vm-100-disk-0.qcow2  compressed.qcow2

включил discard в опции диска, служба fstrim.timer была по умолчанию в гостевой системе активна. В общем с 322 гиг до 123 уменьшился размер файла.

pistoletov
() автор топика
Linux-hardware