LVM thin pool не активируется.

[Megabyte88]

Здравствуйте. Случилась гроза, сервер под Ubuntu 16.04 выключился не смотря на UPS. На сервере папка обмена (/srv/data) под самбой. В /srv/data монтируется тонкий том vg/thinpool/data из LVM.
 
После грозы группа томов (vg) и том (data) в частности перестали активироваться. Пробовал lvconvert --repair vg/thinpool не помогло, пробовал через vgcfrestore восстанавливать мету, эффект тот-же.Раздел data очень нужен, бэкапов нет. Призываю гуру LVM, выхлопы прилагаю:

(Нажмите, чтобы показать/скрыть)

lvchange -aey vg
  device-mapper: resume ioctl on (252:2) failed: Invalid argument
  Unable to resume vg-thinpool-tpool (252:2)
  device-mapper: resume ioctl on (252:2) failed: Invalid argument
  Unable to resume vg-thinpool-tpool (252:2)

(Нажмите, чтобы показать/скрыть)

lvscan
  inactive          '/dev/vg/thinpool' [1.79 TiB] inherit
  inactive          '/dev/vg/data' [950.00 GiB] inherit

(Нажмите, чтобы показать/скрыть)

lvs -a
  LV               VG   Attr       LSize   Pool     Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data             vg   Vwi---tz-- 950.00g thinpool                                               
  [lvol0_pmspare]  vg   ewi-------  16.00g                                                       
  thinpool         vg   twi---tz--   1.79t                                                       
  [thinpool_tdata] vg   Twi-a-----   1.79t                                                       
  [thinpool_tmeta] vg   ewi-ao----  16.00g

(Нажмите, чтобы показать/скрыть)

lvconvert --repair vg/thinpool
truncating metadata device to 4161600 4k blocks
  Transaction id 6469 from pool "vg/thinpool" does not match repaired transaction id 6468 from /dev/mapper/vg-lvol0_pmspare.
  Volume group "vg" has insufficient free space (229 extents): 4096 required.
  WARNING: If everything works, remove "vg/thinpool_meta0".
  WARNING: Use pvmove command to move "vg/thinpool_tmeta" on the best fitting PV.

Ветка на LOR https://www.linux.org.ru/forum/admin/14364232

[bearpuh]

Volume group "vg" has insufficient free space (229 extents): 4096 required.

Места нехватат. Написано же.
Я когда то ремонтировал тонкий LVM, примерно по такому мануалу. Нужно перенести метаданные на другой том.

lvconvert --repair vg/pool

If this is not working - then you can 'swap' metadata out of your thin-pool
using following sequence-

- make sure pool is not active.
- build temporary local LV   (lvcreate -l1 vg -n temp)
- swap this LV with metadata of to-be-repaired pool
  (lvconvert --thinpool vg/fixpool --poolmetadata temp)
- activate 'temp' LV now with pool's metadata
  (lvchange -ay vg/temp)
- repair metadata
  (you may need other 'bigger' volume to restore fixed metadata)
  (i.e.  thin_restore -i /dev/vg/temp -o /dev/vg/biggertemp)
- thin_check restored volume
- thin_dump - and compare  vgcfgrestore & this dump are at the same
  transaction_id state (look at lvm2 metadata for thin pool)
- deactivate again related volumes
- swap repaired LV back
  (lvconvert --thinpool vg/fixpool --poolmetadata repairedtemp)
- try to active repaired thin pool
- remove unneeded volumes from vg....

Пользователь добавил сообщение 31 Июля 2018, 14:54:55:LV том для переноса метаданных нужно на другом hdd создавать!

[Megabyte88]

- thin_dump - and compare  vgcfgrestore & this dump are at the same
  transaction_id state (look at lvm2 metadata for thin pool)

А можно про этот этап поподробнее?
Вот заголовок суперблока тметы из дампа:

Код: [Выделить]

<superblock uuid="" time="3243" transaction="6468" data_block_size="128" nr_data_blocks="29982720">А вот описание пула в беэкапе конфига:

Код: [Выделить]

thinpool {
id = "KeNg4G-2xXn-npjd-eL4E-39Mo-fP0l-b2QbZd"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "datasrv"
creation_time = 1515229743 # 2018-01-06 13:09:03 +0400
segment_count = 1

segment1 {
start_extent = 0
extent_count = 468480 # 1,78711 Terabytes

type = "thin-pool"
metadata = "thinpool_tmeta"
pool = "thinpool_tdata"
transaction_id = 6468
chunk_size = 128 # 64 Kilobytes
discards = "passdown"
zero_new_blocks = 1

message1 {
delete = 3
}
}
}

[bearpuh]

А можно про этот этап поподробнее?

Данный этап - это только проверка.
Предполагается визуально сравнить transaction_id пофиксенного тома с помощью thin_dump - с этим: Transaction id 6469 from pool "vg/thinpool"
Тренироваться нужно на "кошках"!!! - сделать посекторную копию диска и на ней тренироваться. На LOR'e вам это уже говорили.

Тут вспомнил еще один способ, как я раньше делал:
1. Глянуть сколько занимают метаданные lvs -a (Meta%). У меня случилось так, что было занято 100%.
2. Взять другой свободный диск или раздел диска и добавить в ту же группу vg (pvcreate + vgextend)
3. Увеличить размер метаданных в 2 раза от занимаемого размера lvextend -L+XXG vg/thinpool_tmeta
4. Попробовать снова lvconvert --repair vg/thinpool

Возможно увеличивать размер метаданных и не потребуется. Только увеличить группу за счет другого диска/раздела диска.
Пользователь добавил сообщение 06 Августа 2018, 16:21:15:

transaction="6468"

Это ID уже пофиксенного тома с помощью thin_restore?
Если сделать vgcfgbackup/vgcfgrestore на другой временный lvm, transaction ID совпадают?

[Megabyte88]

Тренироваться нужно на "кошках"!!!

Все работы делаю на копии дисков сервера.

lvs -a (Meta%)

По непонятным причинам lvs -a не показывает (Meta%), даже если thinpool_tmeta активен.

Это ID уже пофиксенного тома с помощью thin_restore?

Да, исправил вручную через vgcfgbackup/vgcfgrestore, до этого было transaction="6466".

Взять другой свободный диск или раздел диска и добавить в ту же группу vg (pvcreate + vgextend)

Уже добавлено 500Gb.

3. Увеличить размер метаданных в 2 раза от занимаемого размера lvextend -L+XXG vg/thinpool_tmeta

Размер меты при создании пула указывал 16Gb, так что увеличить её не получится.
Сейчас делаю ручное восстановление меты через обычные логические тома.

Пользователь добавил сообщение 07 Августа 2018, 10:42:46:После ручного восстановления меты пишет вот такое:

Код: [Выделить]

root@datasrv0:/# lvchange -ay -v vg/thinpool
    Using logical volume(s) on command line.
    Activating logical volume "thinpool" exclusively.
    activation/volume_list configuration setting defined: Checking the list to match vg/thinpool
    Creating vg-thinpool_tmeta
  device-mapper: create ioctl on vg-thinpool_tmetaLVM-fA8em3Nk0Xj23fOu00j8iOfH7bUuoXaFvnPub4jAxpWhZHgpD4HqV1fcuywJHSXK-tmeta failed: Устройство или ресурс занято
Выхлоп lvs

(Нажмите, чтобы показать/скрыть)

root@datasrv0:/# lvs -a -o +devices
  LV               VG   Attr       LSize   Pool     Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices         
  data             vg   Vwi---tz-- 950,00g thinpool                                                                 
  [lvol1_pmspare]  vg   ewi-------  16,00g                                                         /dev/sda(4096)   
  thinpool         vg   twi---tz--   1,79t                                                         thinpool_tdata(0)
  [thinpool_tdata] vg   Twi-a-----   1,79t                                                         /dev/sdb(0)     
  [thinpool_tdata] vg   Twi-a-----   1,79t                                                         /dev/sdc(0)     
  [thinpool_tmeta] vg   ewi-------  16,00g                                                         /dev/sda(12289) 

Как быть камрады?
Пользователь добавил сообщение 07 Августа 2018, 12:07:37:

device-mapper: create ioctl on vg-thinpool_tmetaLVM-fA8em3Nk0Xj23fOu00j8iOfH7bUuoXaFvnPub4jAxpWhZHgpD4HqV1fcuywJHSXK-tmeta failed: Устройство или ресурс занято

Оказывается это device-mapper пытался создать новую таблицу для меты но старая не давала. Удалил старую через:

Код: [Выделить]

#dmsetup remove vg-thinpool_tmetaзапустил lvchange -ay vg/thinpool
К сожалению пул не активируется:

Код: [Выделить]

[89372.072938] device-mapper: thin: Data device (dm-1) discard unsupported: Disabling discard passdown.
[89372.072948] device-mapper: thin: 252:2: metadata device (4145152 blocks) too small: expected 4161600
[89372.072952] device-mapper: table: 252:2: thin-pool: preresume failed, error = -22


[bearpuh]

[89372.072948] device-mapper: thin: 252:2: metadata device (4145152 blocks) too small: expected 4161600

Размер не совпадает.
Как вариант - добавить новый том для метаданных меньшего размера и восстановить на него.
Вот workaround - https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201

Еще вариант, попробовать вытащить данные с помощью dmde в режиме "сырые данные" (raw) без указания фс,
но с указанием типов файлов. Он понимает lvm. Я вытаскивал им данные с развалившихся рейдов.
Есть еще UFS Explorer способный на это.

[Megabyte88]

Как вариант - добавить новый том для метаданных меньшего размера и восстановить на него.
Вот workaround - https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201

Весьма изящный метод, буду пробовать.