アカウント名:
パスワード:
これはアプリケーション側のバグの話です。ext4は関係ありませんし、ext3でも起こります。
大抵のOSはLinuxだろうがBSDだろうが遅延書き込みを行っている。しかしアプリケーション側はそのことを全く考慮していない事が多い。その結果データロスが発生するよ、という話です。
アプリケーション側が正しい実装を行っていれば、つまり適切にfsync()やfdatasync()を使用していれば、ext4を使っても何も問題は生じません。
おお、これはまた斬新な。
> 大抵のOSはLinuxだろうがBSDだろうが遅延書き込みを行っている。> しかしアプリケーション側はそのことを全く考慮していない事が多い。> その結果データロスが発生するよ、という話です。
OSが何をして呉れるかではなく、何かをどの様にやっているかを意識しないと、アプリケーションは書けないと言う話ですな?
# 何か本末転倒の様な
あれだよファイルシステム側とOS側の押し付け合いというフリーコミュニティの欠陥にはさまれて右往左往してるユーザーの問題だよ
OSというかファイルシステムの側の問題でしょ。ext4開発者は、そういうリスクがあるのを分かって、それでも高速化のためにリスクをとるほうを選んでるんだから、別にいいんじゃないの?いやなら、ユーザは別のファイルシステムを使えばいいだけのこと。
アプリケーションは関係ありません。というか、アプリケーションがOSの動作の詳細を意識しないといけないのなら、それはそのOSがOSとして失格ということじゃないですかね。アプリから見れば、データロスしていいファイルなんてひとつもないでしょうから、fsync()を必ずかけるということになり、そうすると、遅延書き込みの意味がなくなります。
そういう場合にはファイルシステムを生のまま使わず、DBMSなどのロバストなストレージを利用するものだと思うんだけど。
残念ながらそれは何の解決にもなりません。
DBMSが信頼できると言われているのは redo-log とか言われる機能があるからです。ようするにa) まず何をするのか記録してb) 実際に実行するc) で、終わったことを記録するという処理をする。a と b で二度ディスクに書いてる。
- a が終わる前の場合、アプリケーションに「終わった」とは返さない。ので、それは無かったことになる。- a が終わった後、c が完了する前の場合、a に記録されている内容を再実行する。なのでちゃんと実行される。- c が終わっているならば、そりゃちゃんと終わっています。
というわけ。しかし、問題は「redo-log がちゃんと書き込まれないのにkernelが終わったと返してくる場合」(今回はこれも含む)。
「終わった」というメッセージを受けて、上位アプリケーション(別マシンの場合が多い)は処理を先に進める。しかし、その直後に DBMS が動いているマシンがダウン。ファイルシステムのバグの性で、redo-log への書き込みが終わっておらず、ログの一部が失われたとしましょう。
DBMS上のTransaction は失われます。しかしアプリケーションは処理を進めている。矛盾が生じるわけです。しかも人知れず。大抵、アプリケーション側はDBMSを信じていますのでろくにログを取っていません。結果、取れたはずの座席予約が消失しているとか、行われたはずの商取引が消滅している、なんてことが起こる。
唯一の救いは、Transaction 単位で失われるので、金銭的授受が中途半端に起こる、などということはない、という点です。結果として:
「あれ? このタイミングで売ったはずのドルが手元に残っている???」「あれ? 書いたはずの blog が保存されてない???」
のようにユーザーが「???」と感じるだけで、矛盾はなかなか発見されない。確率論的にはヒューマンエラーのほうがよほど確率が高いので。
なので、DBMSの利用はTransaction単位での障害になるという保障はありますが、Transactionが(少なくとも妥当なレベルで)保護される保障には(この場合は)なりません。
>アプリケーションがOSの>動作の詳細を意識しないといけないのなら、それはそのOSがOSとして失格>ということじゃないですかね。
つまり、WindowsもLinuxもMacOSXも(その他省略)すべてのOSはそのOSの動作を意識して作らなければならないのでOS失格ですか?
#OSフリーのアプリケーションが主流ではない(つーか#Windows専用アプリばかりでさらにWindows内でも互換性に#問題がある)のが現状ではないですか?
なんのためにfsyncがあると思ってるんだ。OSの動作の詳細を意識しないといけないというレベルじゃないと思うんだが。変更してもちゃんと保存しないと消えるという常識的な話だろ。
良いポイントですな。
昔は(4.3BSDとかは)、fsync(2) は不要でした。すべてのシステムコール write(2)は「同期書き込み」だった。なので余りにも遅い、と言うことで libc の fwrite(3) は自前でバッファリングする形で非同期書き込みをしていた。バッファを追い出すには fflush(3) を呼ぶ必要がある。fflush(3)は write(2) を呼び出す。結果として同期書き込みになる。
しかし、その後、kernel 側に非同期書き込みサポートが入った。しかも、そちらがデフォルトになった。
結果、libc の仕様上、fopen(3)されているファイルは「非同期書き込み」でオープンされる。fflush(3)しても fsync(2) は呼ばれず、非同期のままである。
アプリケーションが以上のような歴史的事実を失念していると、データロストが容易に起こる。fopen(3) でファイルを開いたら、fflush(3) 後にファイルデスクリプタを引きずり出して fsync(2) を呼ばなければ、どの OS でもデータロストの可能性が(それもきわめて高い可能性が)存在します。
.
で、その最後の砦が 同期書き込みopen と fsync(2) のはずなのに、それが当てにならないのが Linux。今まであなたのデータが失われなかったのは by luck でしかございません。
> 同期書き込み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)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
*BSDで万全 (スコア:0)
クラッシュでスクリーンがブルーに染まることもありません。
これはアプリケーション側のバグの話 (スコア:0)
これはアプリケーション側のバグの話です。ext4は関係ありませんし、ext3でも起こります。
大抵のOSはLinuxだろうがBSDだろうが遅延書き込みを行っている。
しかしアプリケーション側はそのことを全く考慮していない事が多い。
その結果データロスが発生するよ、という話です。
アプリケーション側が正しい実装を行っていれば、
つまり適切にfsync()やfdatasync()を使用していれば、
ext4を使っても何も問題は生じません。
Re: (スコア:0)
おお、これはまた斬新な。
> 大抵のOSはLinuxだろうがBSDだろうが遅延書き込みを行っている。
> しかしアプリケーション側はそのことを全く考慮していない事が多い。
> その結果データロスが発生するよ、という話です。
OSが何をして呉れるかではなく、何かをどの様にやっているかを意識しないと、アプリケーションは書けないと言う話ですな?
# 何か本末転倒の様な
Re: (スコア:0)
あれだよ
ファイルシステム側とOS側の押し付け合いという
フリーコミュニティの欠陥にはさまれて
右往左往してるユーザーの問題だよ
Re: (スコア:0)
# これはこれで筋が通っている気がする
Re: (スコア:0)
逆じゃないの? (スコア:0)
OSというかファイルシステムの側の問題でしょ。
ext4開発者は、そういうリスクがあるのを分かって、それでも高速化のために
リスクをとるほうを選んでるんだから、別にいいんじゃないの?
いやなら、ユーザは別のファイルシステムを使えばいいだけのこと。
アプリケーションは関係ありません。というか、アプリケーションがOSの
動作の詳細を意識しないといけないのなら、それはそのOSがOSとして失格
ということじゃないですかね。アプリから見れば、データロスしていい
ファイルなんてひとつもないでしょうから、fsync()を必ずかけるという
ことになり、そうすると、遅延書き込みの意味がなくなります。
Re:逆じゃないの? (スコア:1)
結論としてはfsync()やsync()を呼ぶかどうかの選択権は欲しいです。close()したら勝手にfsync()を呼んだのと同じ結果になる、というのは頂けない。
全部の動作が遅くなりそうです。
> アプリケーションは関係ありません。というか、アプリケーションがOSの
> 動作の詳細を意識しないといけないのなら、それはそのOSがOSとして失格
> ということじゃないですかね。
どうしても安全に保存したいファイルに対してfsync()を呼ぶのは詳細でもなんでもない常識レベルです。
BSDだと普通は update が sync()を定期的に(30秒に1回とか)呼んでいるはずなので通常はそこまでは気にしませんが。
updateの間隔以内に電源ブチ切りしたら(気にしないアプリが多いと思うので)そのファイルが壊れますよ。
> アプリから見れば、データロスしていい
> ファイルなんてひとつもないでしょうから、fsync()を必ずかけるという
> ことになり、そうすると、遅延書き込みの意味がなくなります。
一時ファイルやキャッシュファイルのような用途の場合はクラッシュ時のロストOK(というか仕方なし)なのでfsync()は呼びませんので意味はありますね。
Best regards, でぃーすけ
Re: (スコア:0)
少々遅くても安全なファイルシステムが使いたい。<事務屋
Re:逆じゃないの? (スコア:2)
そういう場合にはファイルシステムを生のまま使わず、
DBMSなどのロバストなストレージを利用するものだと思うんだけど。
Re:逆じゃないの? (スコア:1)
残念ながらそれは何の解決にもなりません。
DBMSが信頼できると言われているのは redo-log とか言われる機能があるからです。ようするに
a) まず何をするのか記録して
b) 実際に実行する
c) で、終わったことを記録する
という処理をする。a と b で二度ディスクに書いてる。
- a が終わる前の場合、アプリケーションに「終わった」とは返さない。ので、それは無かったことになる。
- a が終わった後、c が完了する前の場合、a に記録されている内容を再実行する。なのでちゃんと実行される。
- c が終わっているならば、そりゃちゃんと終わっています。
というわけ。しかし、問題は「redo-log がちゃんと書き込まれないのにkernelが終わったと返してくる場合」(今回はこれも含む)。
「終わった」というメッセージを受けて、上位アプリケーション(別マシンの場合が多い)は処理を先に進める。
しかし、その直後に DBMS が動いているマシンがダウン。ファイルシステムのバグの性で、redo-log への書き込みが終わっておらず、ログの一部が失われたとしましょう。
DBMS上のTransaction は失われます。しかしアプリケーションは処理を進めている。矛盾が生じるわけです。しかも人知れず。大抵、アプリケーション側はDBMSを信じていますのでろくにログを取っていません。結果、取れたはずの座席予約が消失しているとか、行われたはずの商取引が消滅している、なんてことが起こる。
唯一の救いは、Transaction 単位で失われるので、金銭的授受が中途半端に起こる、などということはない、という点です。結果として:
「あれ? このタイミングで売ったはずのドルが手元に残っている???」
「あれ? 書いたはずの blog が保存されてない???」
のようにユーザーが「???」と感じるだけで、矛盾はなかなか発見されない。確率論的にはヒューマンエラーのほうがよほど確率が高いので。
なので、DBMSの利用はTransaction単位での障害になるという保障はありますが、Transactionが(少なくとも妥当なレベルで)保護される保障には(この場合は)なりません。
fjの教祖様
Re: (スコア:0)
>アプリケーションがOSの
>動作の詳細を意識しないといけないのなら、それはそのOSがOSとして失格
>ということじゃないですかね。
つまり、WindowsもLinuxもMacOSXも(その他省略)すべてのOSは
そのOSの動作を意識して作らなければならないのでOS失格ですか?
#OSフリーのアプリケーションが主流ではない(つーか
#Windows専用アプリばかりでさらにWindows内でも互換性に
#問題がある)のが現状ではないですか?
Re: (スコア:0)
なんのためにfsyncがあると思ってるんだ。
OSの動作の詳細を意識しないといけないというレベルじゃないと思うんだが。
変更してもちゃんと保存しないと消えるという常識的な話だろ。
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)しても fsync(2) は呼ばれず、非同期のままである。
アプリケーションが以上のような歴史的事実を失念していると、データロストが容易に起こる。fopen(3) でファイルを開いたら、fflush(3) 後にファイルデスクリプタを引きずり出して fsync(2) を呼ばなければ、どの OS でもデータロストの可能性が(それもきわめて高い可能性が)存在します。
.
で、その最後の砦が 同期書き込みopen と fsync(2) のはずなのに、それが当てにならないのが Linux。
今まであなたのデータが失われなかったのは by luck でしかございません。
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の教祖様