私の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）。これらのシン・プロビジョニング・スペースは、2 つの論理ボリュームで構成されます。tp1_tmetaそしてtp1_tierdata_0。一方の論理ボリュームはデータを格納するために使用され、もう一方の論理ボリュームは論理構造を格納するために使用されます。
私の場合、RAID-5がクラッシュしました（/dev/md1）、したがってtp1_tmeta論理ボリューム。
最初のステップは、メタデータダンプ（ファイルサイズ約100 MB）を生成することです。メタデータスナップショットオフセット8388565は、QNAP LVM専用です。
thin_dump /dev/mapper/vg1-tp1_meta0 --metadata-snap=8388565 -o dump.txt
Metadata-snapコマンドラインパラメータに注意してください。メタデータプールは繰り返しスナップショットを実行します。プールがクラッシュした場合は、そのスナップショットにロールバックできます。
2番目のステップでは、プールを復元します。
/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を使用してください。