ext4の変更を辞めて新しくext5を作ったらどうかという意見に対するTheodore Ts'oの回答

EXT4 Data Corruption Bug Hits Stable Linux Kernels - Page 5

つい先日、ext4をぶっ壊すバグが発見されたことを報じたPhoronixの記事に対するフォーラムで、「もうこれ以上ext4を変更するのを辞めて、新しくext5を作ってはどうか」という意見があり、それに対してTheodore Ts'oが回答している。

それは検討したことがある。現在、新機能は実験的機能フラグやマウントオプションで追加されている。そういうデフォルトで有効になっていない実験的な新機能を使う利用者は問題に出くわしやすい。デフォルトで有効になっていない新機能を試したがる利用者を止めることなどできやしない。本番サーバーでext4のかわりにext5を使うことを止めることができないのと同じだ。メタデータチェックサムのようなものがデフォルトで有効になっていないのは、まだ使うべきではないからだ。新機能を試す勇者は貴重であり、テストのためにはありがたいことだ。開発者の環境やregressionテストで見つけられないバグを振るい出すのには、其れしか方法がないのだから。何にせよ、選択するのは利用者だ。実験的な機能を有効にするのは利用者の責任だ。

コードベースをforkして新しい"ext5"を作り出すのにはコストがかかる。すでに、問題は起きている。ext4では修正されたバグが、ext3では修正されていないということだ。今日も、僕はext3では修正されていたマイナーなバグが、ext2では修正されていなかったのを発見した。というわけで、時々、バグがextNでは修正されているが、extN+1に移植するのを忘れてしまうということが起こる。"ext5"とやらを持ち込むと、問題がますます悪くなるだけだ。というのも、バグ修正の移植を忘れる可能性が3倍になるわけだから。

バグ修正といえば、変更を完全にやめるなんてことはできない。なぜなら、バグは常に見つかるからだ。だいたい、ext4を利用するというのは、何百万台ものGoogleのデータセンターのコンピューターで利用するという事で、大量に利用しないと見つからないようなバグもあるのだ。バグを見つけて修正したあとで調べると、全く同じバグがext3にも見つかる。かれこれ10年もエンタープライズlinux環境の、IBMやRed Hatといった大企業で、テストされてきたのにもかかわらずだ。実際、何度か引っかかっているはずだが、とても珍しい事象であり、テスターはおそらく、ハードウェアの故障か宇宙線が原因だと考えたはずだ。実際、大量のコンピューターから得られた、ほとんどがハードウェア障害である大量の失敗報告を観察して、パターンを見つけたからこそ、発見できたバグなのだ。

問題は、時に、バグ修正は新たなバグをもたらすことがある。今回のケースのこのバグは、バグ修正がstableカーネルにbackportされたから、問題が頻繁に起きて、発見できたのだ。冗談ではなく、本当に「すべての変更を止める」と言うのは、一切のバグ修正を行わないという事だ。古いバージョンのLinuxに留まりたいなら、好きにすればいい。RHEL 5やRHEL 4や、時にはRHAS 2.1が選ばれるのは、そのためだ。