「Ext3のコミット間隔を当てにしたアプリケーションは、Ext4でデータロスの恐れあり」記事へのコメント

*BSDで万全

[Anonymous Coward]

おかしなOS使わない限り遅延書き込みなんてあぶなっかしい真似なんかしません。
クラッシュでスクリーンがブルーに染まることもありません。

これはアプリケーション側のバグの話

[Anonymous Coward]

これはアプリケーション側のバグの話です。ext4は関係ありませんし、ext3でも起こります。

大抵のOSはLinuxだろうがBSDだろうが遅延書き込みを行っている。
しかしアプリケーション側はそのことを全く考慮していない事が多い。
その結果データロスが発生するよ、という話です。

アプリケーション側が正しい実装を行っていれば、
つまり適切にfsync()やfdatasync()を使用していれば、
ext4を使っても何も問題は生じません。

Re:

[Anonymous Coward]

全てのアプリがfsync()を必ずするんだったら、そもそも遅延書き込みなんて必要なくね？

Re:

[okky (2487)]

良いポイントですな。

昔は(4.3BSDとかは)、fsync(2) は不要でした。すべてのシステムコール write(2)は「同期書き込み」だった。
なので余りにも遅い、と言うことで libc の fwrite(3) は自前でバッファリングする形で非同期書き込みをしていた。バッファを追い出すには fflush(3) を呼ぶ必要がある。fflush(3)は write(2) を呼び出す。結果として同期書き込みになる。

しかし、その後、kernel 側に非同期書き込みサポートが入った。しかも、そちらがデフォルトになった。

結果、libc の仕様上、fopen(3)されているファイルは「非同期書き込み」でオープンされる。fflush(3)し

--
fjの教祖様

Re:

[Anonymous Coward]

> 同期書き込みopen と fsync(2) のはずなのに、それが当てにならないのが Linux。

これはどこから得た情報ですか?
同種の主張をしている人はいっぱいいるんですけど，根拠を示している人が一人もいないんですよね．
エンタープライズDBMSが動いているLinuxで，fsyncやfdatasyncが信用できないとはちょっと考えられないんですけど．
(ファイルシステムを介さずにデバイスを直接使用している場合も多いけど)

Re:

[okky (2487)]

月刊だった頃の unix Magazine のらすと2号にわたしゃ証拠つきで短期連載をのせていただいているんですが。
# おかげで「ユニマガを潰したのはお前だ」といまだに言われます。はっはっは (|||) そうだったら嫌杉

「証拠を示している人がいない」
のではなく、あなたがものを探していなさすぎるだけです。

--
fjの教祖様

Re:これはアプリケーション側のバグの話

[Anonymous Coward]

ソースの提示ありがとうございます．
unix magazine は捨ててしまって手元にないので，どこか図書館ででも探してみます．

> 「証拠を示している人がいない」
> のではなく、あなたがものを探していなさすぎるだけです。

特定の誰かを責めたいのではありません．
文献があるなら示して欲しいと思い，IDで書いている方にコメントしただけです．
気分を害したなら済みません．

Re:これはアプリケーション側のバグの話

[okky (2487)]

文献を調べるのではなく、自分で実験すれば良いではありませんか。やり方がわからないならまずそれを考えればいい。

実際、実験モデルも立てられないようでは、ググっても何も見つけられないでしょう。検索するべきキーワードを見つけることすらできないでしょうからね。

.

ついでに言うと。。証拠が無い、という人間の大半が日本語しか調べていない、と言うのも特徴ですな。検索するべきキーワードを日本語で引っ張ろうとしている段階で、馬鹿丸出しです。

問題を発見して Linux Community に報告する際の根拠として使うならば、使用言語は絶対英語になります。日本語のページなんぞ作るわけが無い。

「英語で」「実験の際に利用されるであろう用語を」検索すれば、この問題の根拠・証拠なんぞゴロゴロ出てきます。
それを「ない」と言い、「文献を教えろ」と言う段階で、調べていない証拠。正確にはそんなのは調べているうちに入らない程度の行動しかとっていない証拠です。

その態度が無礼以外の何だと?!

--
fjの教祖様