LVM物理ボリュームの不良ブロックを確認するにはどうすればよいですか？
Ext4を使用している場合は、e2fsck -c /dev/sda1 # or whateverコマンドを使用して不良ブロックを確認できます。これにより、ブロックが不良ブロックのiノードに追加され、ブロックが「ブラックリスト」に登録されます。
LVM2物理ボリュームのこれに相当するものは何ですか？その上のファイルシステムはext4ですが、おそらく、基礎となるLVMセットアップが物理ディスク上のデータを移動するため、検出された不良ブロックは無効になります。
つまり、LVMで使用しない不良ブロックを確認するにはどうすればよいですか？
Ext4を使用している場合、
e2fsck -c /dev/sda1コマンドなどを使用して、不良ブロックをチェックできます。これにより、ブロックが不良ブロックのiノードに追加され、ブロックが「ブラックリスト」に登録されます。
e2fsck -cは、基盤となるハードディスク上でbadblocksを実行します。 LVM物理ボリューム上でbadblocksコマンドを直接使用できます（PVが実際にはハードディスクであり、MDソフトウェアRAIDデバイスのような他の種類の仮想デバイスではないと想定）。このコマンドは、extファイルシステムを含むハードディスク上で実行します。
それによってファイルシステムに不良ブロック情報が追加されることはありませんが、ファイルシステムの便利な機能であるとは思いません。ハードディスクは不良ブロックを処理することになっています。
badblocksよりも優れているのは、ディスクでSMARTセルフテストを実行していることです（/dev/sdXをハードディスクのデバイス名に置き換えてください）。
smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less
テスト自体は数時間かかります（正確にどれだけ時間がかかるかがわかります）。完了したら、smartctl -aを使用して結果をクエリし、セルフテストログを探します。 「正常に完了しました」と表示されていれば、ハードディスクは正常です。
言い換えると、LVMで使用しない不良ブロックを確認するにはどうすればよいですか？
言ったように、ハードディスク自体は、破損したブロックを使用しないことを保証し、それらのブロックからデータを再配置します。これは、ファイルシステムまたはLVが実行する必要があることではありません。一方、ハードディスクに不良ブロックがいくつかある場合、それらを再配置するものは必要ありませんが、障害が発生しているためにハードディスク全体を交換したいとします。
LVMは不良ブロックを処理しないと確信しています。基になるストレージが必要です。そして、すべてではないにしても、ほとんどの最新のハードディスクがそうです。セクターへの書き込みを実行する必要があるかもしれませんが、ディスクはそれを再マップする必要があります。 （たとえば、smartctl /dev/sda -t offlineなどを使用して、最初にオフラインの表面スキャンを実行するために必要になる場合があります）。
そうは言っても、LVMは、たとえばpvmoveのように、ユーザーが要求しない限り、実際にはデータを移動しません。したがって、ext4 badblocks機能を使用できます。 pvmoveを実行する場合は、不良ブロックを再確認する必要があります。一般的な操作（lvextendなど）はデータを移動しません。
LVMは「論理エクステント0〜99は物理エクステント200〜299である」というマップを保持しているため、データを移動しません。拡張すると、「論理エクステント100〜199は物理エクステント100〜199です」と追加されます。または「論理エクステント100〜149は物理エクステント50〜99、論理エクステント150〜199は物理エクステント140〜189」です。 LVMは、物理エクステントが順序正しくなかったり、連続していないことを気にしません。
pvckはLVMメタデータをチェックできます。その一貫性はファイルシステムの仕事です。 LVMはボリューム管理に関するものだけなので、特定のエクステントを構成するスペースが悪いかどうかを気にする必要はありません。より高いレベルのソフトウェアがそれらの問題をキャッチするからです。とにかく、LVMメタデータは、物理ボリュームの最初（オプションで最後のセクターも）だけを占めます。
適度に大きいPV（生産で表示されるような）の最初と最後のセクターだけが同時に失敗した場合、天文学的に考えられないほど、世界で最も幸運なことが起こります。それ以外の場合、管理者がドライブの複数のセクターで障害が発生していることを知っていれば、ほとんどの人は「ハードドライブが永続的に故障しており、交換する必要がある」にこのようなものを提出するだけで問題ありません。
pvckがエラーを返した場合は、LVMメタデータが/etc/lvmのどこかにバックアップされているかどうかを確認できます。ある場合は、pvcreateにバックアップコピーを指定して--restorefileを実行できます。
構文：
pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>
例：
pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2
復元が機能しない場合（たとえば、最初のセクターが不良である場合）は、上記をやり直すことができますが、--metadatacopies 2を設定する（またはそのまま実行することもできます）。 PVの最初と最後のセクターへのメタデータ。 pvscanが起動時にそのことを行うと、両方の場所がチェックされ、メタデータが見つかった場合は、チェックサムに対してそれらが検証されます。最初のセクターでチェックサムが失敗し、最後のセクターで成功した場合、致命的でないエラーメッセージが表示されます。
一種の手作業と苦痛ですが、これもまた、人々がBTRFSでボリューム管理をやり直すことに興奮している理由の一部です。デロベルトが述べた理由、そしてデータの継続性を確実に確実に必要とする人々が通常RAIDを実行し、バックアップ戦略を持っているため、ほとんどの場合それは実際にはそれほど問題ではありません。