3年前のネタらしいので、知っている人にとっては今更なのかもしれませんが、、
もともとは「tmpfs は本当に容量が動的なのか (naoyaのはてなダイアリー)」で問題提起されてて、Linuxで実装されてるtmpfsについての議論がいろいろあったようです。詳細は、「tmpfs は本当に容量が動的なのか (革命の日々！)」や「続： tmpfs は本当に容量が動的なのか (革命の日々！)」に書かれてます。
で、結局のところ一言で言うと「tmpfs について (ぴょぴょぴょ？Linuxとかプログラミングの覚え書き)にあるように、
tmpfsは "swap可能なramディスク"である．
らしいです。
ところがどっこい、もしswapがないシステムだったら？ガリガリっとtmpfsにファイルを書いていって、んでメモリが足りなくなったら、ひたすらOOM-Killerが走って止まらなくなります。一度こうなってしまうと、OOM-Killerが走り続けてもはや何もできなくなります。swapがないシステムなんて知るかよーとかとか素人の私が叫んだところで、ないものはないんで、どうしようもないです。というか、RAMディスクなので、ファイルを書いてもガリガリいわんわな。SSDが広く普及したら「ガリガリって何？」とか言われるんだろうなぁ。ああ、脱線しすぎ。
tmpfsにファイルを書いた場合、まぁ当たり前っちゃー当たり前ですが、4KBのブロックサイズとしてメモリを食います。つまり、サイズ1byteのファイルを1000個作ったら、4MB食います。(正確には、おそらくファイル一覧を管理するための領域としてさらにファイルの数の平方根くらいのオーダーの追加メモリを食ってる模様。ディレクトリ1個作っても512byteくらいメモリ食ってる模様) そんな当たり前のことを考えずに動かしたシステムで「合計***byteのサイズしか書いてないのにメモリが足りなくなって・・・」とかぼーたれながら2日ほどをムダにつぶしてしまったのは、ここだけの内緒じゃなくて、私の恥としてさらし続けといてください・・・
まー、サイズ計算をアプリでするなら、上記の4KBブロックを考慮してやりゃすむんでそれだけの話です。が、本当にそうすべきなのかと。たぶん正攻法としては、tmpfsをマウントするときに上限サイズをきちっと決めて、アプリに限界を超えたサイズを書きせないようにするのが正攻法でしょうね。「mount -t tmpfs -o size=2m tmpfs /dev/shm」とか。
下回り屋さんとしては上記の対応でいいんですが、どうせ tmpfsに2MBしか回せないようじゃ今の仕様を満たすものを作るには厳しいので、やはりメモリを増やせという要求を通していた方がよかった気がします。(すでに過去形) ああ、今や値段差20セントか。どこの誰だ、160円とかいってたやつは。ここまで頭悩まして設計してまでしてけちる値段なのか本当に疑問。
tmpfsの挙動を調べるために最初に紹介した記事周辺のブログ読みあさったんですが、メモリ消費量についてはあまりわからなかったので、仕方なく linux/mm/shmem.c あたりを1時間くらい読んで、んで読んでもわかるかボケーという結論に達して、実際に実験して実測しました。私はプログラムを書くのが苦手なプログラマなので、サンプルプログラムを作るのに苦労しましたが、結局実験した方が早くてかつ確実でした。
結局何を書きたかったんだろ。とりあえず、こんなだめな後輩ですいません kosakiさん。
というようなことを、深夜2時の会社で考えてました。っと思ったら、すでに夢の中でした。
