Linuxのstableカーネルにext4をぶっ壊すバグが発見される

[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カーネルを使っている環境のシステム管理者は震え上がるのだろうか。