[Phoronix] EXT4 Data Corruption Bug Hits Stable Linux Kernels
このバグは、3.6.2でもたらされ、以前の安定版カーネルにもback-portされているので、3.4の最新の安定版カーネルにまで影響が及ぶらしい。
Theodore Ts'oによれば、この問題は、カーネルを短期間で二度正常にリブートすることで起こるのだそうだ。そのため、一般の普通のディストロを使っている利用者は、まずこのバグに出くわすことはない。しかし、サスペンドやハイバネートのかわりにリブートを使うラップトップ利用者や、カーネル開発者には、容易に問題が起こりうるのだとか。
なんだかだいぶ反響があるので追記。Theodore Ts'oのメールより
LKML: Theodore Ts'o: Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)
多分問題が分かった。問題のコミットは、おそらく、
14b4ed22a6 (upstream commit eeecef0af5e):
jbd2: don't write superblock when if its empty
初出はv3.6.2。
このバグを含むコミットによって、問題が極めてまれに起こる原因は、ジャーナルの開始ブロックがゼロであるとき、ファイルシステムをアンマウントするときにジャーナルのtruncateに失敗するからだ。これは、マウント、アンマウントを極めて素早く行い、ログのwrapがなされないと起こる。一度起きたとしても、問題ではない。ジャーナルを再生できるので、追加のトランザクションを再生すればよい。しかし、二度起きると、古い真当なトランザクションのアップデートされないにもかかわらず、前回のマウント時より新しいトランザクションが、さらに最新のトランザクションにより書き込まれる。この時、追加のトランザクションの再生を行うと、メタデータブロックが、とても変な状態になる。
やれやれ、このパッチを僕がレビューしたときに問題に気がつけなくてごめん。以下のパッチでバグを解決できると思う。他のext4開発者のレビューを受けたならば、ただちに、Linuxにプッシュするよ。
というわけで、正確にはリブートではなく、二度素早くマウント、アンマウントする場合に問題になる。あまりに短時間で頻繁にマウント、アンマウントを繰り返し、しかも最近のstableカーネルを使っている環境のシステム管理者は震え上がるのだろうか。
No comments:
Post a Comment