私はUbuntu 12.10のLVMでスナップショットを試しました。 6.5GiBスナップショット論理ボリュームを作成し、ソースをいくつか変更した後、スナップショットを再びマージして元に戻すことにしました。すべてがうまくいくようですが、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
システムログから：
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確認しました。しかし、まだセグフォルトが心配です。私のデータがfsckが捕捉できない方法で混乱する可能性はありますか？私が試しているボリュームはバックアップボリュームで、ここにバックアップしたすべてのファイルシステムはまだ機能しているため、最初から再起動してバックアップできます。しかし、一方で増分バックアップ履歴を維持したいと思います。私はこのバックアップを信頼できることを確認したいだけです。
答え1
はい、これは間違いなくバグです。しかし、心配しないでください。 LVMはこの問題を処理するのに十分スマートです。 pvmove中に電源が切れたことがあるので、サーバーを再度開いて以前のpvmoveを「キャンセル」して起動するだけです。上。
まず、使用しているツールがカーネルプロセスへのユーザースペースインターフェイスにすぎないことを知っておくことが重要です。 LVMはカーネル内にあるので、カーネルにパニックが発生しない限り、すべてが正常です。 pvmoveやlvchangeなどのユーザースペースツールは、私たちのためにLVMと対話し、カーネルに「まだ終わりましたか？どうなりましたか？」または「今、私たちはどれくらい進んだのか」と尋ねます。問題は、lvchangeが正常に完了した後にlvchange segfaultが発生することです。最近修正されたバグのようです。したがって、すべてのシステムアップデートがあることを確認することをお勧めします。）
一般に、LVMに問題があるかどうかについては、あまりにも躊躇したり、編集を増やしてはいけません。 LVMは、これらの予期しないエラーを非常にうまく処理するように設計されています（使用しているツールだけでなく直接影響を与えても）。これは、従来のパーティション化の代わりにボリュームマネージャを使用する点の一部です。君に何が起こったら困るだけだ本物悪いことが起こったり、深く考えずに何かをすることになります。 LVMはブロックではなくエクステントごとに機能し、コピー操作が正常に完了するまでコピーされたエクステントを有効にし、元のエクステントを無効にしません。これにより、コピーされた範囲の半分が未割り当てとしてマークされ、後続のツールがそれを上書きします。これは私のpvmoveとlvchangeの両方に当てはまります。
編集する：
見ているこのメーリングリストに関するお知らせ、マージが実際に「内部的に」いかに働くか詳細に説明できます。
マージが有効になっている間、ソースデバイスへのすべてのアクセスはマージ中のスナップショットに[移動]されます。マージが完了すると、ソースターゲットがシームレスに再ロードされ、マージされたスナップショットが削除されます。この間、[ビスナップショット]ファイルシステムはマウントされたままになることがあります。
知っておくと面白いと思いました。
答え2
重い作業はカーネル（デバイスマッパー）によって処理されますが、データ自体は安全でなければなりません。しかし、LVMユーザーレベルのツールは依然として重要な目的を果たしています。これにより、デバイスマッパー自体が知らない、または気にしない保存内容、場所、および保存方法に関するLVMメタデータが保存されます。
これらのメタデータの更新中にLVMツールでセグメントエラーが発生すると、データが失われる可能性があります。ある意味では、LVMは分割ファイルシステムです。破損したLVMメタデータは、欠落しているファイルシステムのスーパーブロックと同じです。これはまさにほぼすべての変更です/etc/lvm/...。
Segfaultingは決して良いことではありません。 LVMツールでこれが発生した場合は、そのツールの使用を中止して安定したLVMバージョンに切り替える必要があります。問題を追跡し、永久に修正できるように、バグがディストリビューションに報告されることがあります。