アカウント名:
パスワード:
Ubuntuのext4でのみ問題が起こるようにも読める文章ですが、カーネルの問題であって基本的にディストリビューションは関係ないですよね？(もちろん独自にパッチをバックポート、とかはあるでしょうが)
本家記事は元のバグレポートがUbuntuに対してなされてるのがわかるので意味が通るんですがこっちでは何が何やら、ミスリードチックです。
Ext4の問題でも、Ext3のコミット間隔を当てにしたアプリケーションの問題でもなく、Linuxカーネルの問題……ってことですよね？何のことなのか訳分からなくてLinux環境ではファイルシステムを意識してソフト開発しないといけないのかなんて思ってました。
Ext3のコミット間隔を当てにしたアプリケーションの問題ですよ。
要はPOSIXで制定されている以上の事を求めるプログラマ多すぎ、というのが結論。 Ext3の挙動が標準であると思い込んでアプリケーション書いていたら、その挙動はExt3固有で POSIXにはそんなこと書いてなかった。 それで、Ext4じゃその挙動が変わっちゃったという話みたい。
Ted Tsoがバグレポートの中 [launchpad.net]で書いていることを引用すると、
1.a) open and read file ~/.kde/foo/bar/baz1.b) fd = open("~/.kde/foo/bar/baz", O_WRONLY|O_TRUNC|O_CREAT) --- this truncates the file1.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)1.d) close(fd)
> 5秒間隔のコミットに依存したプログラムというのは上記の1)と2)。
5秒と60秒では、単にリスクの大小の程度問題であって、5秒だとOKだけど60秒だとNGってのは言い過ぎではないかと。
それに、これはファイルシステム側の問題であって、アプリ側の問題ではないと思う。
ext4は、そういうリスクを承知の上で60秒という設定をしているはず。そのリスクを受け入れるかどうかはユーザーが決めればいいこと。もちろんユーザーはそういうリスクを知らされている必要があるけど、そのうえで受け入れられなければ別のファイルシステムを使えばいいし、受け入れる人がいなくなれば、ext4は淘汰されてしまうことでしょう。
それに、遅延書き込みへの防衛としてアプリ側でsyncを頻発したら、遅延書き込みのメリットがなくなってしまいますよね。それは、リスクを承知でext4を選択したユーザーにとっても不利益のはず。
>> 5秒間隔のコミットに依存したプログラムというのは上記の1)と2)。
>5秒と60秒では、単にリスクの大小の程度問題であって、5秒だとOKだけど60秒だとNGってのは言い過ぎではないかと。
一応、直後に書いたたように、>> Ext3においては、コミット間隔が短かったのでクラッシュした際のデータロスとかが比較的少かった。>> だけど、Ext4では、そのコミット間隔の長さに由来して、今迄存在したけど顕在化しなかったこの問題が浮上したと。
なので、この問題自体は重要視されていなかっただけでずっと存在していたんでしょう。
> それに、これはファイルシステム側の問題であって、アプリ側の問題ではないと思う。
この点については、"Not a bug" [slashdot.org]に始まる本家のスレッドで大フレームウォーがあった模様。一方はPOSIXを盾にこれはアプリケーションのバグと主張し、他方は複雑なファイルシステムのメカニズムをアプリケーションプログラマが知っていることを前提とするのは間違っていると主張。また、高級言語では、fsync()相当のものがないのもあるよーとも。
Linuxデスクトップユーザの私は、Ext3で現在満足しているので、今回の騒動に関しては人柱乙(だって、Ubuntu 9.04 alphaだし)というのが正直な感想。Ext4はミッションクリティカルなサーバ等を指向しているのかなあとも思った。また、btrfs, ZFS, tux3, reiser4等も同様で、今回みたいなことがこれらでもおこらないとの保証はないとのこと。
> それに、遅延書き込みへの防衛としてアプリ側でsyncを頻発したら、遅延書き込みのメリットがなくなって> しまいますよね。それは、リスクを承知でext4を選択したユーザーにとっても不利益のはず。
これに関しては、再びTed Ts'o [launchpad.net]からですが、Ext3 data=ordered モードでfsyncが遅かったのは、Ext3特有の問題(全てのデータを一気に書き込む)、Ext4においてはもっとスマートだとのこと(fsyncされたファイルのみを一気に書き込み、その他のファイルは徐々に書き込む)。よって、Ext4のfsyncはExt3のそれよりも性能がいいとか。
ここら辺のことに関して、私は全然知識がないので有識者の意見が待たれるところ。
抜粋解説ありがとうございます、参考になりました。
> 一応、直後に書いたたように、> >> Ext3においては、コミット間隔が短かったのでクラッシュした際のデータロスとかが比較的少かった。> >> だけど、Ext4では、そのコミット間隔の長さに由来して、今迄存在したけど顕在化しなかったこの問題が浮上したと。>> なので、この問題自体は重要視されていなかっただけでずっと存在していたんでしょう。
おっしゃるとおりですね。# これを「問題」ととらえるかどうかは、その人の立場/見方によりかわると思いますが、笑。
ここで話題になっている ext3やext4の「コミット間隔」は、ファイルシステム内でデータをバッファから書き出す定期実行間隔のことなので、仮にext4の60秒が5秒になっても、最後のコミットから事故までの間で2次記憶にはデステージされていないデータがある(かもしれない)ことにはかわらないです。
本質的に、ユーザが意図するようにバッファから書き出してもうらうには、a)ユーザが書き出しを指示するか(=fsync/syncなどを発行するか)、a)ユーザがバッファードライトの禁止を指示するか、しかありません。
アプリケーション側でデータ破壊の問題を何も考えず安直にやりたいのであれば、ライトスルーで書く(前述bの方法)のでしょうが、でもそんなことをしていたら、IO性能は出ないので、「データの意味・整合性を知っている(自ら作り出している)」アプリケーション側で、意識的に整合性のポイントをつくって、使い分ける必要があります(前述aの方法)。DBなど、性能と信頼性を要求するものは、こういうところまできちんと考えて設計しています(が、現実には、怪しいモノもありますが)。
なお、ext4でコミット間隔を長くした理由には、ext4がエクステント方式を採用していることも関係しています。ext3などはブロック方式ですが、特に(DBなどの)巨大なファイルを作ったときなどはそのファイルを構成するブロックの間接参照が深くなりIO性能が低下する傾向にあります。
そこでext4はエクステント方式(連続するブロックを開始オフセット/長さで表現するデータ構造)としたことで、これを解決することを目指しています。(エクステント方式はext4が初めてではありません)。エクステント方式で性能を出すためには、できるだけ連続したブロックを割り当てることが大切ですが(フラグメンテーションの回避が課題になりますが)、そのためには、できるだけライトデータをバッファして、連続して一気に書き込むことが重要になり(これだけではないですが)、そのため、「意図的に」コミット間隔を長くとっています。
言い換えれば、コミットを(FS内で)乱発するのは、そもそもの設計の狙いに反しているので、そのあたりは慎重に考える必要があるでしょうね。(ここの設計者の見極めが、今回のTruncate指定でのコミットのパッチにうまく現れていると考えます)
ちなみに、ファイルを更新中にプロセス終了や電源断でデータ破壊というのは、(バッファが全く関係ないわけではないですが)本質的には別の話ですね。これはバッファードライトでなくても起きうる話で。(データの整合性がとれるポイントまでは)データを上書きしないように気をつけよう(CopyOnWriteしよう)、と。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
Ubuntu関係なくね？ (スコア:2, 参考になる)
Ubuntuのext4でのみ問題が起こるようにも読める文章ですが、
カーネルの問題であって基本的にディストリビューションは関係ないですよね？
(もちろん独自にパッチをバックポート、とかはあるでしょうが)
本家記事は元のバグレポートがUbuntuに対してなされてるのがわかるので意味が通るんですが
こっちでは何が何やら、ミスリードチックです。
Re: (スコア:0)
Ext4の問題でも、Ext3のコミット間隔を当てにしたアプリケーションの問題でもなく、Linuxカーネルの問題……ってことですよね？
何のことなのか訳分からなくてLinux環境ではファイルシステムを意識してソフト開発しないといけないのかなんて思ってました。
Re: (スコア:0)
Ext3のコミット間隔を当てにしたアプリケーションの問題ですよ。
Re: (スコア:0)
突然のシステムダウンから復帰したときに、色んなファイルがゼロバイトになる現象のようなんですど、複数のファイルがごっそりゼロバイトになることに未対応であるアプリがあるってだけなんじゃないかと。
Re: (スコア:5, 参考になる)
要はPOSIXで制定されている以上の事を求めるプログラマ多すぎ、というのが結論。
Ext3の挙動が標準であると思い込んでアプリケーション書いていたら、その挙動はExt3固有で POSIXにはそんなこと書いてなかった。
それで、Ext4じゃその挙動が変わっちゃったという話みたい。
Ted Tsoがバグレポートの中 [launchpad.net]で書いていることを引用すると、
Re: (スコア:0)
> 5秒間隔のコミットに依存したプログラムというのは上記の1)と2)。
5秒と60秒では、単にリスクの大小の程度問題であって、5秒だとOKだけど60秒だとNGってのは言い過ぎではないかと。
それに、これはファイルシステム側の問題であって、アプリ側の問題ではないと思う。
ext4は、そういうリスクを承知の上で60秒という設定をしているはず。そのリスクを受け入れるかどうかは
ユーザーが決めればいいこと。もちろんユーザーはそういうリスクを知らされている必要があるけど、
そのうえで受け入れられなければ別のファイルシステムを使えばいいし、受け入れる人がいなくなれば、
ext4は淘汰されてしまうことでしょう。
それに、遅延書き込みへの防衛としてアプリ側でsyncを頻発したら、遅延書き込みのメリットがなくなって
しまいますよね。それは、リスクを承知でext4を選択したユーザーにとっても不利益のはず。
Re: Ubuntu関係なくね？ (スコア:4, 参考になる)
>> 5秒間隔のコミットに依存したプログラムというのは上記の1)と2)。
>5秒と60秒では、単にリスクの大小の程度問題であって、5秒だとOKだけど60秒だとNGってのは言い過ぎではないかと。
一応、直後に書いたたように、
>> Ext3においては、コミット間隔が短かったのでクラッシュした際のデータロスとかが比較的少かった。
>> だけど、Ext4では、そのコミット間隔の長さに由来して、今迄存在したけど顕在化しなかったこの問題が浮上したと。
なので、この問題自体は重要視されていなかっただけでずっと存在していたんでしょう。
> それに、これはファイルシステム側の問題であって、アプリ側の問題ではないと思う。
この点については、"Not a bug" [slashdot.org]に始まる本家のスレッドで大フレームウォーがあった模様。
一方はPOSIXを盾にこれはアプリケーションのバグと主張し、他方は複雑なファイルシステムのメカニズムをアプリケーションプログラマが知っていることを前提とするのは間違っていると主張。
また、高級言語では、fsync()相当のものがないのもあるよーとも。
Linuxデスクトップユーザの私は、Ext3で現在満足しているので、今回の騒動に関しては人柱乙(だって、Ubuntu 9.04 alphaだし)というのが正直な感想。
Ext4はミッションクリティカルなサーバ等を指向しているのかなあとも思った。
また、btrfs, ZFS, tux3, reiser4等も同様で、今回みたいなことがこれらでもおこらないとの保証はないとのこと。
> それに、遅延書き込みへの防衛としてアプリ側でsyncを頻発したら、遅延書き込みのメリットがなくなって
> しまいますよね。それは、リスクを承知でext4を選択したユーザーにとっても不利益のはず。
これに関しては、再びTed Ts'o [launchpad.net]からですが、
Ext3 data=ordered モードでfsyncが遅かったのは、Ext3特有の問題(全てのデータを一気に書き込む)、Ext4においてはもっとスマートだとのこと
(fsyncされたファイルのみを一気に書き込み、その他のファイルは徐々に書き込む)。よって、Ext4のfsyncはExt3のそれよりも性能がいいとか。
ここら辺のことに関して、私は全然知識がないので有識者の意見が待たれるところ。
Re: (スコア:0)
ファイルシステムのメカニズムを知っている人に修正を加えてもらえばいいのに・・・
何のためのオープンソースだか訳分からん。
他所から見ると単に自分の知らない事を指摘されて逆ギレしてるようにしか見えない。
Re: (スコア:0)
Re: Ubuntu関係なくね？ (スコア:3, 参考になる)
抜粋解説ありがとうございます、参考になりました。
> 一応、直後に書いたたように、
> >> Ext3においては、コミット間隔が短かったのでクラッシュした際のデータロスとかが比較的少かった。
> >> だけど、Ext4では、そのコミット間隔の長さに由来して、今迄存在したけど顕在化しなかったこの問題が浮上したと。
>
> なので、この問題自体は重要視されていなかっただけでずっと存在していたんでしょう。
おっしゃるとおりですね。
# これを「問題」ととらえるかどうかは、その人の立場/見方によりかわると思いますが、笑。
ここで話題になっている ext3やext4の「コミット間隔」は、ファイルシステム内でデータをバッファから書き出す定期実行間隔のことなので、仮にext4の60秒が5秒になっても、最後のコミットから事故までの間で2次記憶にはデステージされていないデータがある(かもしれない)ことにはかわらないです。
本質的に、ユーザが意図するようにバッファから書き出してもうらうには、a)ユーザが書き出しを指示するか(=fsync/syncなどを発行するか)、a)ユーザがバッファードライトの禁止を指示するか、しかありません。
アプリケーション側でデータ破壊の問題を何も考えず安直にやりたいのであれば、ライトスルーで書く(前述bの方法)のでしょうが、
でもそんなことをしていたら、IO性能は出ないので、「データの意味・整合性を知っている(自ら作り出している)」アプリケーション側で、意識的に整合性のポイントをつくって、使い分ける必要があります(前述aの方法)。
DBなど、性能と信頼性を要求するものは、こういうところまできちんと考えて設計しています(が、現実には、怪しいモノもありますが)。
なお、ext4でコミット間隔を長くした理由には、ext4がエクステント方式を採用していることも関係しています。
ext3などはブロック方式ですが、特に(DBなどの)巨大なファイルを作ったときなどはそのファイルを構成するブロックの間接参照が深くなりIO性能が低下する傾向にあります。
そこでext4はエクステント方式(連続するブロックを開始オフセット/長さで表現するデータ構造)としたことで、これを解決することを目指しています。
(エクステント方式はext4が初めてではありません)。
エクステント方式で性能を出すためには、できるだけ連続したブロックを割り当てることが大切ですが(フラグメンテーションの回避が課題になりますが)、そのためには、できるだけライトデータをバッファして、連続して一気に書き込むことが重要になり(これだけではないですが)、そのため、「意図的に」コミット間隔を長くとっています。
言い換えれば、コミットを(FS内で)乱発するのは、そもそもの設計の狙いに反しているので、そのあたりは慎重に考える必要があるでしょうね。
(ここの設計者の見極めが、今回のTruncate指定でのコミットのパッチにうまく現れていると考えます)
ちなみに、
ファイルを更新中にプロセス終了や電源断でデータ破壊というのは、(バッファが全く関係ないわけではないですが)本質的には別の話ですね。
これはバッファードライトでなくても起きうる話で。
(データの整合性がとれるポイントまでは)データを上書きしないように気をつけよう(CopyOnWriteしよう)、と。