我的 LVM 似乎处于不一致的状态：
[~] # vgchange -a y
device-mapper: reload ioctl on (252:16) failed: No data available
device-mapper: reload ioctl on (252:16) failed: No data available
10 logical volume(s) in volume group "vg1" now active
RAID-5（Linux 多磁盘）已崩溃，重建后无法再激活。我能做些什么。
一些诊断输出，请告诉我您是否需要更多信息：
[~] # pvs -v --segments
Using physical volume(s) on command line.
PV VG Fmt Attr PSize PFree Start SSize LV Start Type PE Ranges
/dev/md1 vg1 lvm2 a-- 21.80t 0 0 36864 lv544 0 linear /dev/md1:0-36863
/dev/md1 vg1 lvm2 a-- 21.80t 0 36864 16384 tp1_meta6 0 linear /dev/md1:36864-53247
/dev/md1 vg1 lvm2 a-- 21.80t 0 53248 5662624 [tp1_tierdata_2_fcorig] 0 linear /dev/md1:53248-5715871
/dev/sdf vg1 lvm2 a-- 7.28t 6.78t 0 16384 tp1_meta1 0 linear /dev/sdf:0-16383
/dev/sdf vg1 lvm2 a-- 7.28t 6.78t 16384 16384 tp1_meta2 0 linear /dev/sdf:16384-32767
/dev/sdf vg1 lvm2 a-- 7.28t 6.78t 32768 16384 tp1_meta3 0 linear /dev/sdf:32768-49151
/dev/sdf vg1 lvm2 a-- 7.28t 6.78t 49152 16384 tp1_meta4 0 linear /dev/sdf:49152-65535
/dev/sdf vg1 lvm2 a-- 7.28t 6.78t 65536 16384 tp1_meta0 0 linear /dev/sdf:65536-81919
/dev/sdf vg1 lvm2 a-- 7.28t 6.78t 81920 16384 tp1_meta5 0 linear /dev/sdf:81920-98303
/dev/sdf vg1 lvm2 a-- 7.28t 6.78t 98304 16384 tp1_meta7 0 linear /dev/sdf:98304-114687
/dev/sdf vg1 lvm2 a-- 7.28t 6.78t 114688 16384 [tp1_tmeta] 0 linear /dev/sdf:114688-131071
/dev/sdf vg1 lvm2 a-- 7.28t 6.78t 131072 1776649 0 free
[~] # vgs -v
Using volume group(s) on command line.
VG Attr Ext #PV #LV #SN VSize VFree VG UUID VProfile
vg1 wz--n- 4.00m 2 12 0 29.08t 6.78t 1VJkVt-vfPX-vBAv-KtuC-kKDU-1CDd-1RBuel
[~] # lvs -v
Using logical volume(s) on command line.
target_name:thin-pool
LV VG #Seg Attr LSize Maj Min KMaj KMin Pool Origin Data% Meta% Move Cpy%Sync Log Convert LV UUID LProfile
lv1 vg1 1 Vwi---t--- 21.00t -1 -1 -1 -1 tp1 TuCexj-MyZA-uIkX-kzVp-KBWt-dHVQ-Iq6t27
lv288 vg1 1 Vwi---t--- 2.00t -1 -1 -1 -1 tp1 f0jKvz-Jm4G-JZ8l-8ysp-2RDS-cDWJ-Ue0VCR
lv544 vg1 1 -wi-a----- 144.00g -1 -1 252 0 SHXwIE-iAMG-5ctO-g0RG-55P9-jeke-df3S4n
tp1 vg1 1 twi-aot--- 21.60t -1 -1 252 6 0.00 0.02 Hk25P5-gQkc-pJHw-jKfL-U9cB-2vBF-74lr2L
tp1_meta0 vg1 1 -wi-a----- 64.00g -1 -1 252 8 foHo1k-gciB-VJcM-9CRV-ySC0-0I9A-rshk3A
tp1_meta1 vg1 1 -wi-a----- 64.00g -1 -1 252 9 8bloJL-stWn-1O3r-j5jQ-vlqv-DpNe-waeIef
tp1_meta2 vg1 1 -wi-a----- 64.00g -1 -1 252 10 AvXCmL-zVIg-xTCm-ZtOz-1VGT-EEBU-cugNA8
tp1_meta3 vg1 1 -wi-a----- 64.00g -1 -1 252 11 EVcMvv-S0BC-N0Xh-5Pzj-3Rrj-RkFb-ZTgMw8
tp1_meta4 vg1 1 -wi-a----- 64.00g -1 -1 252 12 YCgXIz-eZxy-N2Wz-8Exl-9dJw-syIb-dVeux4
tp1_meta5 vg1 1 -wi-a----- 64.00g -1 -1 252 13 H35ozg-XyJ3-rjPP-ipTz-DIDV-JNPA-fSg54E
tp1_meta6 vg1 1 -wi-a----- 64.00g -1 -1 252 14 fl5ACi-7uNv-h5Fw-71NI-G8nT-93sz-VgMdR5
tp1_meta7 vg1 1 -wi-a----- 64.00g -1 -1 252 15 ap8Nds-GACe-9dXu-BZ6J-H1df-HwOc-pQ7VnX
答案1
在寻找解决方案时，我发现了这个线程：https://charles-gagnon.medium.com/repair-a-thin-pool-a42f41169541。不幸的是，该线程对我来说并没有真正的帮助，因为我的问题无法通过解释的步骤解决，但作者提到蔡明鸿这对他有帮助。所以我也联系了他，他帮我解决了这个问题：
首先你必须了解我的问题的基本结构和案例：
我有一个卷组VG1这是在/dev/md1：
[~] # pvdisplay
--- Physical volume ---
PV Name /dev/md1
VG Name vg1
PV Size 21.80 TiB / not usable 2.50 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 5715872
Free PE 0
Allocated PE 5715872
PV UUID C6femQ-nMRN-d8F0-f2pk-BRVA-pQuH-Dv3skX
该卷组中有很多逻辑卷，但有问题的逻辑卷是TP1：
--- Logical volume ---
LV Name tp1
VG Name vg1
LV UUID Hk25P5-gQkc-pJHw-jKfL-U9cB-2vBF-74lr2L
LV Write Access read/write
LV Creation host, time MAML-NAS01, 2021-08-03 13:01:08 +0200
LV Pool metadata tp1_tmeta
LV Pool data tp1_tierdata_0
LV Status available
# open 3
LV Size 21.60 TiB
Allocated pool data 32.45%
Allocated pool chunks 14697037
Allocated metadata 0.69%
Current LE 5662224
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 4096
Block device 252:6
该逻辑卷不是存储在卷组内的简单数据块。它是一个精简配置空间，动态填充卷组的定义区域。在这个精简配置的空间内，您可以创建逻辑卷（在我的例子中1级和LV288）。这样的精简配置空间是由两个逻辑卷构建的：tp1_tmeta和tp1_tierdata_0。一个逻辑卷用于存储数据，另一个逻辑卷用于存储逻辑结构。
就我而言，RAID-5 崩溃了（/dev/md1），从而也tp1_tmeta逻辑卷。
第一步是创建元数据转储（该文件大约 100MB）。请注意，元数据快照偏移 8388565 特定于 QNAP LVM：
thin_dump /dev/mapper/vg1-tp1_meta0 --metadata-snap=8388565 -o dump.txt
请注意metadata-snap 命令行参数：元数据池执行循环快照。当您的池崩溃时，您可以回滚到此类快照。
在第二步中，您恢复该池：
/sbin/pdata_tools thin_restore -i dump.txt -o /dev/mapper/vg1-tp1_meta6
就我而言，我已将其恢复为vg1-tp1_meta6因为这是唯一打开的元数据池/dev/md1（参见我的问题）。
然后你必须告诉 tp1 这现在是池元数据：
lvconvert vg1/tp1 --poolmetadata vg1/tp1_meta6
lvconvert --thinpool vg1/tp1 --poolmetadata vg1/tp1_meta6
lvconvert vg1/tp1 --swapmetadata --poolmetadata vg1/tp1_meta6
lvconvert --type tier-thin-pool --thinpool vg1/tp1 --poolmetadata vg1/tp1_meta6
之后vg1-tp1_meta6逻辑卷将绑定到tp1并隐藏。现在您应该能够激活精简逻辑卷及其内部逻辑卷。
就我而言，修复命令（经常在其他线程中提到）会在每次调用它时创建另一个用于修复的元数据设备，但随后崩溃，因为在我的情况下不可能修复元数据（无需回滚）。因此我不得不删除/dev/sdf从我的卷组：
vgsplit vg1 vg2 /dev/sdf
在我的情况下，内部逻辑卷也被损坏。逻辑卷 lv1 和 lv288 使用 ext4 进行格式化，我必须在其中进行文件系统检查。使用 e2fsck_64 进行文件系统检查。