☰

LVM物理ボリュームで不良ブロックを確認するには？

tag-icon • tag-icon lvm badblocks
LVM物理ボリュームで不良ブロックを確認するには？

ext4では、コマンドを使用して不良ブロックを確認できますe2fsck -c /dev/sda1 # or whatever。その後、ブロックを不良ブロックiノードに追加し、ブロックを「ブラックリスト」にします。

LVM2物理ボリュームの場合、これは何と同じですか？ファイルシステムはext4ですが、デフォルトのLVM設定が物理ディスク上のデータを移動すると、検出された不良ブロックが無効になる可能性があります。

つまり、LVMを使用せずに不良ブロックをどのように確認できますか？

答え1

ext4を使用すると、そのコマンドe2fsck -c /dev/sda1または他のコマンドを使用して不良ブロックを確認できます。その後、ブロックを不良ブロックiノードに追加し、ブロックを「ブラックリスト」にします。

e2fsck -cbadblocksプライマリハードディスクで動作します。badblocksextファイルシステムを含むハードディスクと同様に、LVM物理ボリュームで直接このコマンドを使用できます（PVが実際にハードディスクであり、MDソフトウェアRAIDデバイスなどの他の種類の仮想デバイスではないと仮定）。

これは、ファイルシステムに何らかの不良ブロック情報を追加しませんが、ハードドライブが不良ブロックを処理するようになっているファイルシステムの有用な機能ではないと思います。

badblocksディスクでSMARTセルフテストを実行するよりもはるかに優れています（/dev/sdXハードドライブのデバイス名に置き換えます）。

smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less

テスト自体には数時間かかります（正確にどのくらいの時間がかかります）。完了後、smartctl -aクエリ結果からセルフテストログを取得できます。 「成功的に完了しました」と表示された場合は、ハードドライブに問題はありません。

つまり、LVMを使用せずに不良ブロックをどのように確認できますか？

前述したように、ハードドライブ自体は破損したブロックを使用しないようにし、そのブロックからデータを再配置します。これはファイルシステムやLVが実行する必要はありません。一方、ハードドライブに不良ブロックが複数ある場合、そのブロックを再配置する必要はありませんが、エラーが発生したため、ハードドライブ全体を交換しようとします。

答え2

私はLVMがプライマリストレージの不良ブロックを処理しないと確信しています。これはすべてではありませんが、ほとんどの最新のハードドライブに当てはまります。そのセクターに書き込む必要がありますが、ディスクはそのセクターを再マップする必要があります。 （たとえば、最初にオフラインサーフェススキャンを実行するために必要な場合がありますsmartctl /dev/sda -t offline。）

つまり、LVMはユーザーが要求しない限り実際にデータを移動しませんpvmove。したがって、ext4 badblocks 機能を使用できます。実行している場合は、不良ブロックを再確認してくださいpvmove。データを移動する一般的な操作（例：）はありませんlvextend。

LVMは、「論理範囲0〜99は物理範囲200〜299」というマッピングを維持し、拡張すると「論理範囲100〜199は物理範囲100〜199」のみを追加するため、拡張時にデータは移動されません。あるいは、「論理拡張領域１００～１４９は物理拡張領域５０～９９であり、論理拡張領域１５０～１９９は物理拡張領域１４０～１８９」である。 LVMは、物理的な範囲が順序が間違っているか連続していない場合は気にしません。

答え3

pvckLVMメタデータを確認でき、一貫性はファイルシステムの操作です。 LVMはボリューム管理にのみ関与しているため、特定の範囲を構成する領域が破損しているかどうかを気にする必要はありません。より高いレベルのソフトウェアがこれらの問題を捉えるからです。それにもかかわらず、LVMメタデータは物理ボリュームの最初（最後）セクタだけを占めます。

かなりの規模のPV（生産で見られるような）の最初のセクターと最後のセクターが同時に失敗した場合、天文学的に不可能であるため、基本的に世界最悪の幸運を享受します。そうではなく、管理者がドライブのさまざまなセクタにエラーがあることを知っていると、ほとんどの人は「ハードドライブが永久にエラーが発生して交換が必要です」の下にこのような内容を送信します。

エラーが返されると、LVMメタデータがどこかにpvckバックアップされていることを確認できます。/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を使用したボリューム管理リメイクに熱狂する理由の1つです。ほとんどの場合、これはデロバートが言及した理由とデータの継続性を絶対に保証する必要がある人が通常RAIDを実行し、バックアップ戦略を持っているため大きな問題ではありません。

答え4

論理ボリュームをマウントするときは、不良ブロックを確認してください。

ステップ1：論理ボリュームの名前を確認します。

ll /dev/mapper

ステップ2：不良ブロックを確認してください。

sudo badblocks -o bad-blocks.txt -n -s -v -f /dev/mapper/ubuntu--vg-my_drive--lv

関連情報