Q&A
0バイトファイルが新規作成で初めてオープンされ、ライトバックされないかまたは途中までライトバックされてもクローズしない内に電源断になったらファイルの存在は確定していないのですから、存在自体が無くなっても仕方が無いのではと思うのですが、そうなることのlinux上の仕様などエビデンスのようなものを回答にお求めでしょうか。
以前、以下の質問をしたのですが、新たな問題が発生し困っているため
お力を貸してください。
以前の質問
・電源断の後に立ち上げたらファイルサイズが0バイトになってしまう
https://teratail.com/questions/238041
上記の問題は、キャッシュの保存期間とHDへの書き込み間隔を短くすることで対応が出来ました。
dirty_writeback_centisecs
dirty_expire_centisecs
この状態で改めて確認したところ、0バイトのファイルは格段に少なくなったのですが
0バイトファイルのタイムスタンプから電源断までの時間で生成されたファイルは存在自体が無かったことになっています。
電源断直前のlsコマンドでは確かにファイルが存在しています。
2段階のキャッシュのような仕組みがあって、段階によって0バイトになったり、存在が残らなかったりするのでしょうか？
その為のext4/ジャーナリングファイルシステムだとも思います。
一体どんなOSをお望みでしょう？
・電源が突然切れても、ファイルの書き込みはちゃんとする。
・電源が突然切れても、再起動できる。
cateyeさん、回答がしやすいので先に回答させていただきます。
私が望んでいるのはこの現象の原因を知ることと、OSの設定でこのようなファイルが生成されるのを抑えることが出来るか？という事です。
dodox86さん、ライトバックが未完による現象であるというエビデンスは確かに欲しいです。
ファイルサイズが0バイトのものがライトバック未完によるものではないか？と予想しています。
ext4/ジャーナリングファイルシステムのキーワードで調査してみます。
＞taminaさん
ライトバックキャッシュの無効化について、こちらはUbuntuですが:
http://ubuntuhandbook.org/index.php/2014/01/disable-disk-caching-prevent-data-loss/
Linuxのライトバックキャッシュはコマンドで無効にすることはできるものの、Linux自体がライトバックキャッシュ付きの動作を前提にしているため、無効にすると劇的にパフォーマンスが悪くなり、更に不安定になると言う報告を見かけたことがあります。ですので自己責任ですね。
ファイルサイズが0になるなどの個々の現象は、Linuxカーネルはじめファイルシステムドライバーのソースを自分で追わないと、完全な証拠は得られないでしょう。そもそもそれはバグではなく仕様（制限）の範囲だと思います。ファイルシステムにおけるジャーナリングは、電源断のような場合でもファイルシステムを含んだデータに矛盾が無いように、最大限、保障する機能です。「ファイルサイズが0になる理由」と言う質問自体については私自身は質問者さんが求める明確な回答を持たないので、以上、コメントのみです。
別口のアドバイスとしては、Red Hat Linuxなのであれば、一部は商用なのですからサポート窓口に問い合わせた方が責任ある回答を得られるのではないでしょうか。
回答3件
0
重要な点ですが、電源が突然落ちる、より先は、あまりソフトウェア的に想定する意味がないのです。
電源が突然落ちる場合、ハードウェア故障や、落雷、隕石などいくらでも想定できてしまうため、それらにどこまで対処するか、という話になるわけです。
急に電源が壊れる、というような事を想定するのは意味は無くはないですが、それは、どちらかというと、冗長化された電源やUPS(無停電電源装置)によって、解決すべき問題です。
あるいはマザーボードが壊れる、ということを想定するならば、Fault tolerantなサーバーを導入すべきです。
突然の電源断が発生することを想定するようなシステムは、fault tolerant なサーバーです。
もし隕石が降ってきても、ていう話なら、月面にサーバーを置いてミラーリングするしかありません。
安価な(といっても高いですが)一般的なサーバーはそういう障害は、そもそも、想定外なのです。
(更に重要なことですが、全ての対策は、想定があって、その想定に対する対策があるものであって、想定外が起きたら、それは言葉通り『想定外』で、対策はできていないし、その事態が起きたら、被る障害やリスクは目をつぶる、というものです)
ソフトウェアは、基本的には『ハードウェアが正しく動作している、環境下』しか想定していません。
それ以上は、ベストエフォートで、できるだけ耐えられるようにする、ものです。
したがって、基本的にpepperleafさんが書いておいでのように、何があっても、基本的には、保証されません。
想定すべきではないし(必要十分というニュアンスで)必要もないからです。
Fault tolerantなサーバーは、調べて貰えばわかりますが、それはそこそこ高価ですが、複数ノードで構成されて、万一単一ノードが落ちても、他のノードでサービスできるようになっています。
しかし、当然ですが、全てのノードが突発的に電源断した場合は、当然、動作は保証されません。
万一電源が落ちても、いいように、copy on writeや、ジャーナリングなどの機能をLinuxは提供しますが、これは、例えば、kernel panicや突発電源断でも、システムが壊れにくくなるような工夫であって、電源がいつ落ちてもいい、というものではありません。
基本的には電源がいつ落ちていいというよりも、電源が落ちないようにし、電源が失われた場合も、UPSなどを用いて可能な限り正常に終了させる。が対策として先にあるべきです。
なので、OSの仕組みとして、どこまで処理が進んでいって、どこで止まったから、0byteファイルになった、とか、ファイルシステムが壊れたとかいうのは、そういうところまで処理はできたけれど、後続処理ができなかったから、そうなっただけであって、ソフトウェアとして意図したものではありません。
投稿2020/02/18 00:35
退会済みユーザー
総合スコア0
そういう意味では、自分の回答も RedHat Linuxでの、電源断に対応する方法という視点が無かったか?
0
電源断直前のlsコマンドでは確かにファイルが存在しています。
はたしてそれは、本当に HDDに書かれたものなのか?
キャッシュ上のものかも知れません。
昔のUnixのシャットダウンは、おまじないみたいに、シングルユーザーで、
cmd
1sync 2sync 3sync 4halt
としてました。
要するに、ディスクへの書き込みを強制する。
Linuxでも、突然の電源断の動作は保証されません。(Windowsもだけど)
システムが壊れる事もあります。
それを回避するにために、UPSとか使います。
ここで、電源断を検出し、システムに対し、シグナルを送り、適切な停止処理を行う事で、安全な終了処理が行えます。
周辺機器の一部は電源断でも壊れないものが増えてます。
HDDなんかでも、ヘッドが安全領域に退避など、、。
これはどうしているかと言うと、電源断時に、内部のコンデンサに蓄えられた電荷で、安全領域に移動するなどの処理をしているから。PCなんかだと専用バッテリ搭載しないと無理ではないかと思います。
通常のシステムでは、電源断と同時に OSを含めたシステムが停止するので、OSは何もできません。
組込みなどでは、それを考慮し、ハードウェアを含めた設計をします。
投稿2020/02/14 12:19
編集2020/02/17 12:37総合スコア6385
キャッシュ上のデータだという事は認識しています。
キャッシュ上のデータでも、電源断に対して2通りの振舞をする（ファイルサイズが0バイトになる、ファイルが無かったことになる）ため質問させて頂いております。
この振舞の違いは、何故で、OSの設定などで、このようなファイルを少なくすることは出来るのでしょうか？
バッテリバックアップの無いシステムの場合、電源断で何が起きても不思議はありません。(昔は、ハードも壊れた)
ファイル名を書き込んだところで、落ちたら、名前だけ。その前だったら、何も残らない。もっともタイミング次第で、ファイルシステムに矛盾が生じて再起不能となります。...まあ、lost+found に入るのが多数か?
ノートPCなんかだと、バッテリがあり、残りが一定量以下の処理って設定があるので、OSでの対応はできますが。
改めて書きますが、ハードウェア(バッテリ等)のサポートが無い限り、突然の電源断に対応する術はありません。
0
自己解決
電源断に対して、2種類の振舞をする件については分かりませんでした。
ファイルの書き込み先ディスクを同期書き込みオプションを付けてマウントすることで電源断が発生した場合でもファイルが正しく保存されていることを確認しました。
投稿2020/03/24 05:29
総合スコア136
あなたの回答
tips
プレビュー
