アカウント名:
パスワード:
これはアプリケーション側のバグの話です。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使わせてくれと心の中で叫んだような記憶が……。
文献を調べるのではなく、自分で実験すれば良いではありませんか。やり方がわからないならまずそれを考えればいい。
実際、実験モデルも立てられないようでは、ググっても何も見つけられないでしょう。検索するべきキーワードを見つけることすらできないでしょうからね。
.
ついでに言うと。。証拠が無い、という人間の大半が日本語しか調べていない、と言うのも特徴ですな。検索するべきキーワードを日本語で引っ張ろうとしている段階で、馬鹿丸出しです。
問題を発見して Linux Community に報告する際の根拠として使うならば、使用言語は絶対英語になります。日本語のページなんぞ作るわけが無い。
「英語で」「実験の際に利用されるであろう用語を」検索すれば、この問題の根拠・証拠なんぞゴロゴロ出てきます。それを「ない」と言い、「文献を教えろ」と言う段階で、調べていない証拠。正確にはそんなのは調べているうちに入らない程度の行動しかとっていない証拠です。
その態度が無礼以外の何だと?!
より多くのコメントがこの議論にあるかもしれませんが、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使わせてくれと心の中で叫んだような記憶が……。
Re: (スコア:0)
unix magazine は捨ててしまって手元にないので，どこか図書館ででも探してみます．
> 「証拠を示している人がいない」
> のではなく、あなたがものを探していなさすぎるだけです。
特定の誰かを責めたいのではありません．
文献があるなら示して欲しいと思い，IDで書いている方にコメントしただけです．
気分を害したなら済みません．
Re:これはアプリケーション側のバグの話 (スコア:1)
文献を調べるのではなく、自分で実験すれば良いではありませんか。やり方がわからないならまずそれを考えればいい。
実際、実験モデルも立てられないようでは、ググっても何も見つけられないでしょう。検索するべきキーワードを見つけることすらできないでしょうからね。
.
ついでに言うと。。証拠が無い、という人間の大半が日本語しか調べていない、と言うのも特徴ですな。検索するべきキーワードを日本語で引っ張ろうとしている段階で、馬鹿丸出しです。
問題を発見して Linux Community に報告する際の根拠として使うならば、使用言語は絶対英語になります。日本語のページなんぞ作るわけが無い。
「英語で」「実験の際に利用されるであろう用語を」検索すれば、この問題の根拠・証拠なんぞゴロゴロ出てきます。
それを「ない」と言い、「文献を教えろ」と言う段階で、調べていない証拠。正確にはそんなのは調べているうちに入らない程度の行動しかとっていない証拠です。
その態度が無礼以外の何だと?!
fjの教祖様