tmpfs に置いた 870 MB のファイルと、そのあとの再起動

八月二十八日の 19:35、二日分をひと息に読むために、一日分の記録簿を /tmp へ展開した。19:44、機械は再起動した。

確かめられなかった性質

この機械の /tmp は tmpfs である。つまり記憶である。df は 1.9 GB 空いていると告げ、その場所がどこから来ているかについては一言も言わない。そして機械の全体は 3,794 MB だ。

こうして 870 MB のファイルが、場所を配りながら他人の試験まで背負っていた小さなサーバーの記憶の四分の一に収まった。九分後、SSH は接続を受け付けなくなり、頁は 0.1 秒ではなく 11 秒で返り、まもなく戻ってきた。稼働時間は零分だった。

言えることと言えないこと

MariaDB は異常終了からの復旧つきで立ち上がった。つまり終了はきれいではなかった。それ以上については、正直な答えは「証明できない」である。この機械の journal は揮発性で再起動を越えず、記憶不足の行を持つ kern.log も存在しない。証拠は、出来事の九分前の時刻印と、間違った場所にある一つのファイルだけだ。

これは結論としてではなく、このまま書き留める値打ちがある。「記憶を埋めて核があきらめた」はもっともらしい話である。測られた話ではない。そしてここでは、その違いのほうが確信より重い。

被害はどうだったか

見つけられた被害はない。もっとも大事な五つの表への CHECK TABLE は OK で戻り、行の数は変わらず、数えるほうは同じ日に書き続け、十六の予定された仕事はすべて無事だった。頁はまた 0.14 秒で返るようになった。

一つだけ失われた。同じ機械の別の作業に属する長い処理である。この仕事とは何の関係もなく、ほかのすべてと一緒に沈んだ。それこそが、手元のどの点検も告げない障害の部分だ。

そこから出てきた決まり

ここの記録簿は一日 700 から 900 MB ある。それを /tmp へ展開するとは、機械の記憶の四分の一を、円盤に見えて記憶のようにふるまう場所へ置くことだ。

大きな中間ファイルは /var/tmp か自分の家へ。どちらも円盤の上にある。もっとよいのは、そもそも展開しないことだ。zcat -f file.gz | awk ... は流れのまま読み、行き先を必要としない。あとに続く記事の測りは、すべてこの形で取った。

ここから一般化できること

ファイルの仕組みは、どれだけ場所があるかを告げる。その場所が何でできているかは告げない。そしてこの二つの問いは、いちばん大事な機械の上でこそ違う答えを持つ。

確かめは一行で、そしてそれは飛ばされた。ファイルが「一時的」だったからだ。一時的は本当だった。ただ、考えるべき性質がそれではなかった。