回答:
ext4を使用している場合は、コマンド
e2fsck -c /dev/sda1などで不良ブロックを確認できます。これにより、ブロックが不良ブロックiノードに追加され、ブロックが「ブラックリスト」に追加されます。
e2fsck -cbadblocks基礎となるハードディスクで実行されます。badblocksハードディスクでコマンドを使用するのと同じように、LVM物理ボリュームで直接コマンドを使用できます（PVが実際にはハードディスクであり、MDソフトウェアRAIDデバイスのような他の種類の仮想デバイスではない場合） extファイルシステムが含まれています。
これにより、ファイルシステムに不良ブロック情報が追加されることはありませんが、それがファイルシステムの有用な機能であるとは思いません。ハードディスクは不良ブロックを処理することになっています。
badblocksディスク上でSMARTセルフテストを実行するよりも優れ/dev/sdXています（ハードディスクのデバイス名に置き換えてください）：
smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less
テストifselfには数時間かかります（正確にどれくらいの時間がかかるかがわかります）。完了したら、で結果をクエリできますsmartctl -a。セルフテストログを探します。「正常に完了しました」と表示されている場合、ハードディスクは正常です。
言い換えれば、LVMで使用しない不良ブロックをチェックするにはどうすればよいですか？
前述したように、ハードディスク自体は破損したブロックを使用しないようにし、それらのブロックからデータを再配置します。これは、ファイルシステムまたはLVが行う必要のあることではありません。一方、ハードディスクにいくつかの不良ブロックがある場合、それらを再配置するものは必要ありませんが、故障しているためハードディスク全体を交換する必要があります。
dd。思ったよりも頻繁に、メディアは実際に正常であり、データが破損しているだけなので、再書き込みすることなく上書きできます。
dd」-しかし、あなたはまだそうすべきではないでしょう。md急襲があれば、それはあなたのための問題を大事にすることができます。@derobertはおそらく、ディスクがmdレイドの一部ではない場合に何をすべきかを知っているでしょう:)
LVMは不良ブロックを処理しないと確信しています。基礎となるストレージに期待しています。そして、すべてではありませんが、ほとんどの場合、最新のハードディスクがそうです。セクタへの書き込みを実行する必要があるかもしれませんが、ディスクはそれを再マッピングする必要があります。（たとえば、を使用して、最初にオフラインの表面スキャンを実行する必要がある場合がありますsmartctl /dev/sda -t offline）。
とは言うものの、LVMは、たとえばで尋ねない限り、実際にデータを移動しませんpvmove。したがって、ext4 badblocks機能を使用できます。実行した場合は、不良ブロックを再確認する必要がありますpvmove。lvextendデータを移動する一般的な操作（など）はありません。
LVMは「論理エクステント0〜99は物理エクステント200〜299」というマップを保持しているので、Extendはデータを移動しません。拡張すると、「論理エクステント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でボリューム管理の冗長性を得ることに興奮している理由の一部です。ほとんどの場合、derobertが述べた理由からそれほど問題ではありません。また、データの継続性を確実に確実に必要とする人々は通常RAIDを実行し、バックアップ戦略を持っているためです。
-c何か完全なナンセンスを呼び出す前に何が起こるかを確認することができます。