アカウント名:
パスワード:
これはアプリケーション側のバグの話です。ext4は関係ありませんし、ext3でも起こります。
大抵のOSはLinuxだろうがBSDだろうが遅延書き込みを行っている。しかしアプリケーション側はそのことを全く考慮していない事が多い。その結果データロスが発生するよ、という話です。
アプリケーション側が正しい実装を行っていれば、つまり適切にfsync()やfdatasync()を使用していれば、ext4を使っても何も問題は生じません。
良いポイントですな。
昔は(4.3BSDとかは)、fsync(2) は不要でした。すべてのシステムコール write(2)は「同期書き込み」だった。なので余りにも遅い、と言うことで libc の fwrite(3) は自前でバッファリングする形で非同期書き込みをしていた。バッファを追い出すには fflush(3) を呼ぶ必要がある。fflush(3)は write(2) を呼び出す。結果として同期書き込みになる。
しかし、その後、kernel 側に非同期書き込みサポートが入った。しかも、そちらがデフォルトになった。
結果、libc の仕様上、fopen(3)されているファイルは「非同期書き込み」でオープンされる。fflush(3)し
> 同期書き込みopen と fsync(2) のはずなのに、それが当てにならないのが Linux。
これはどこから得た情報ですか?同種の主張をしている人はいっぱいいるんですけど，根拠を示している人が一人もいないんですよね．エンタープライズDBMSが動いているLinuxで，fsyncやfdatasyncが信用できないとはちょっと考えられないんですけど．(ファイルシステムを介さずにデバイスを直接使用している場合も多いけど)
月刊だった頃の unix Magazine のらすと2号にわたしゃ証拠つきで短期連載をのせていただいているんですが。# おかげで「ユニマガを潰したのはお前だ」といまだに言われます。はっはっは (|||) そうだったら嫌杉
「証拠を示している人がいない」のではなく、あなたがものを探していなさすぎるだけです。
当該記事は読んでいませんが、kernel 2.4.20かそこらの頃にこの問題に気付いて頭を抱えていた記憶が。あと確か以前kernel.orgのMLでこの手の問題が起きたとき、メンテナ側がそろって「遅延書き込みで良いだろ」って結論に行ったんでしたっけ？ そんなこんなを知ってどうすればLinuxで確実な書き込みを行わせられるかを調べたり実験していた記憶が……。(心の中で泣きまくってた)# 突然の電源断があり得るシステムにLinux載せなきゃいけなかったため
んでこのとき調べた範囲では、BSD系ならsyncかければDisk側のWrite bufferのflushまではやってくれる。Solarisならflushした後のverifyまでやってくれるってんでいっそSolaris使わせてくれと心の中で叫んだような記憶が……。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
*BSDで万全 (スコア:0)
クラッシュでスクリーンがブルーに染まることもありません。
これはアプリケーション側のバグの話 (スコア:0)
これはアプリケーション側のバグの話です。ext4は関係ありませんし、ext3でも起こります。
大抵のOSはLinuxだろうがBSDだろうが遅延書き込みを行っている。
しかしアプリケーション側はそのことを全く考慮していない事が多い。
その結果データロスが発生するよ、という話です。
アプリケーション側が正しい実装を行っていれば、
つまり適切にfsync()やfdatasync()を使用していれば、
ext4を使っても何も問題は生じません。
Re: (スコア:0)
Re: (スコア:4, 参考になる)
良いポイントですな。
昔は(4.3BSDとかは)、fsync(2) は不要でした。すべてのシステムコール write(2)は「同期書き込み」だった。
なので余りにも遅い、と言うことで libc の fwrite(3) は自前でバッファリングする形で非同期書き込みをしていた。バッファを追い出すには fflush(3) を呼ぶ必要がある。fflush(3)は write(2) を呼び出す。結果として同期書き込みになる。
しかし、その後、kernel 側に非同期書き込みサポートが入った。しかも、そちらがデフォルトになった。
結果、libc の仕様上、fopen(3)されているファイルは「非同期書き込み」でオープンされる。fflush(3)し
fjの教祖様
Re: (スコア:0)
> 同期書き込みopen と fsync(2) のはずなのに、それが当てにならないのが Linux。
これはどこから得た情報ですか?
同種の主張をしている人はいっぱいいるんですけど，根拠を示している人が一人もいないんですよね．
エンタープライズDBMSが動いているLinuxで，fsyncやfdatasyncが信用できないとはちょっと考えられないんですけど．
(ファイルシステムを介さずにデバイスを直接使用している場合も多いけど)
Re: (スコア:2, 参考になる)
月刊だった頃の unix Magazine のらすと2号にわたしゃ証拠つきで短期連載をのせていただいているんですが。
# おかげで「ユニマガを潰したのはお前だ」といまだに言われます。はっはっは (|||) そうだったら嫌杉
「証拠を示している人がいない」
のではなく、あなたがものを探していなさすぎるだけです。
fjの教祖様
Re:これはアプリケーション側のバグの話 (スコア:2, 参考になる)
当該記事は読んでいませんが、kernel 2.4.20かそこらの頃にこの問題に気付いて頭を抱えていた記憶が。
あと確か以前kernel.orgのMLでこの手の問題が起きたとき、メンテナ側がそろって「遅延書き込みで良いだろ」って結論に行ったんでしたっけ？ そんなこんなを知ってどうすればLinuxで確実な書き込みを行わせられるかを調べたり実験していた記憶が……。(心の中で泣きまくってた)
# 突然の電源断があり得るシステムにLinux載せなきゃいけなかったため
んでこのとき調べた範囲では、BSD系ならsyncかければDisk側のWrite bufferのflushまではやってくれる。Solarisならflushした後のverifyまでやってくれるってんでいっそSolaris使わせてくれと心の中で叫んだような記憶が……。