☰

心配すべきでしょうか? LVM スナップショットをマージするときに syslog にセグメント違反が報告される (元のスナップショットに戻す)

tag-icon • tag-icon linux lvm segmentation-fault snapshot
心配すべきでしょうか? LVM スナップショットをマージするときに syslog にセグメント違反が報告される (元のスナップショットに戻す)

私はちょうど Ubuntu 12.10 の LVM でスナップショットを試していました。6.5 GiB のスナップショット論理ボリュームを作成し、元のボリュームにいくつか変更を加えた後、スナップショットをマージして元に戻すことにしました。すべて順調に進んでいるように見えましたが、syslog に LVM 関連のセグメント違反メッセージがいくつかあることに気付きました。

入力されたコマンド:

sudo lvcreate -L6.5G -n backup_snapshot -s /dev/mapper/vg0-backup
# made some miscellaneous writes
sudo lvconvert --merge /dev/vg0/backup_snapshot
sudo umount /snapshot/backup
sudo umount /backup
sudo lvchange -an /dev/vg0/backup
sudo lvchange -ay /dev/vg0/backup
sudo mount /backup

syslog から:

Apr 12 04:57:10 bournemouth kernel: [ 5260.813253] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:00:11 bournemouth kernel: [ 5441.841401] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:02:00 bournemouth kernel: [ 5551.438487] show_signal_msg: 48 callbacks suppressed
Apr 12 05:02:00 bournemouth kernel: [ 5551.438495] lvm[5813]: segfault at 28 ip 000000000047f319 sp 00007fff60873de0 error 4 in lvm[400000+d9000]
Apr 12 05:02:01 bournemouth kernel: [ 5552.458797] lvchange[6449]: segfault at 28 ip 000000000047f319 sp 00007fff935f4380 error 4 in lvm[400000+d9000]

その後、元の LV をアンマウントし、スナップショットがもう存在しないことを確認して、fsck.ext4 -fその LV 上で実行しました。その方法では問題ありませんでした。しかし、セグメント違反がまだ心配です。fsck が検出できないような何らかの方法でデータが台無しになっている可能性はありますか? 実験していたボリュームはバックアップ ボリュームで、そこにバックアップしたすべてのファイル システムはまだ正常に動作しているので、最初からやり直してバックアップし直すことができます。しかし、一方で、増分バックアップの履歴は保持しておきたいと思います。これらのバックアップを信頼できるという安心感が欲しいのです。

答え1

はい、それは間違いなくバグですが、心配しないでください。LVM はこのような問題に対処できるほどスマートです。以前、pvmove の途中で電源が切れたことがありましたが、基本的にサーバーを再度オンにして、古い pvmove を「キャンセル」し、最初からやり直すだけで済みました。

まず、使用するツールはカーネル プロセスへのユーザー空間インターフェイスにすぎないことを知っておくことが重要です。LVM はカーネル内に存在するため、カーネルがパニックに陥らない限りは問題ありません。pvmove や lvchange などのユーザー空間ツールは、LVM とインターフェイスするだけで、あとはただ座ってカーネルに「もう終わった? 結果はどうだった?」または「どこまで進んでいる?」と尋ねるだけです (具体的な問題は、lvchange が正常に完了した後に lvchange がセグメント違反になるというものです)。最近修正されたバグのようですそのため、すべてのシステムアップデートが適用されていることを確認する必要があります。

一般的に言えば、LVMでトラブルに巻き込まれるかどうかについて、あまり神経質になったり、偏執的になったりする必要はありません。LVMはこのような予期しないエラーをうまく処理するように設計されており（使用しているツールだけでなく、LVMに直接影響する場合でも）、その保証は、従来のパーティションよりもボリュームマネージャを使用するポイントの一部です。トラブルになるのは、本当に悪いことが起きるか、よく考えずに何かを行うかです。LVM はブロックではなくエクステント単位で動作し、コピー操作が正常に完了するまで、コピーされたエクステントをアクティブにしたり、元のエクステントを非アクティブにしたりしません。そうすることで、半分コピーされたエクステントは未割り当てとしてマークされたままになり、後続のツールはそれを上書きするだけです。これは、私の pvmove とあなたの lvchange の場合です。

編集：

見つめているこのメーリングリストのお知らせ、マージが実際に内部でどのように機能するかについて、より詳細な説明を得ることができます。

マージがアクティブの間、元のデバイスへのアクセスはすべて、マージ中のスナップショットに向けられます。マージが終了すると、元のターゲットはシームレスに再ロードされ、マージ中のスナップショットは削除されます。この間、[非スナップショット] ファイルシステムはマウントされたままになります。

知っておくと面白いかもしれないと思った

答え2

重要な処理はカーネル (デバイス マッパー) によって処理されるため、データ自体は安全です。ただし、LVM ユーザーランド ツールには依然として重要な機能があります。LVM メタデータ (何がどこにどのように保存されているか) は保持されますが、デバイス マッパー自体はこれを認識しておらず、気にも留めません。

LVM ツールがこのようなメタデータの更新中にセグメント エラーを起こすと、データが失われる可能性があります。ある意味では、LVM はパーティション用のファイル システムです。LVM メタデータが破損すると、ファイル システムのスーパーブロックが失われることになります。そのため、ほぼすべての変更が に記録/バックアップされます/etc/lvm/...。

セグメント違反は決して良いことではありません。LVM ツールがセグメント違反を起こす場合は、そのツールの使用をやめて、安定して動作する LVM バージョンに切り替える必要があります。また、ディストリビューションにバグを報告して、問題を追跡し、完全に修正できるようにしてください。

関連情報