小型RAMベース/tmp

Question

/tmpに16MBしか使用しないと、一部のソフトウェアで問題が発生する可能性がありますか？

はい、一部のソフトウェアで書き込みを行い、/tmpそのソフトウェアまたは他のソフトウェアがすでにパーティションを満たしている場合は可能です。通常、これは、誤ったシステム構成、利用可能なリソースに対する合法的な制限、または他のソフトウェアの誤動作を示す可能性があります。いずれにせよ、作成したいソフトウェアがそれ自体で解決策を見つけようとする可能性が低く、エラーが発生します。

一部のソフトウェアは大容量ファイルを作成できると仮定し、/tmp公正に言うと、これは公正な仮定です。この問題は、「不適切な構成」エラーカテゴリに属します。

自分に尋ねなければならない最初の質問は、「RAMを使用するとどのような利点がありますか/tmp？」です。最も明確なことは次のとおりです。潜在的な利点は、RAMへのアクセスがディスクへのアクセスよりもはるかに高速であることです。しかし、これらの明らかな潜在的な利点は、次の理由で実際にはそれほど大きくはないでしょう。

それにもかかわらず、システムは頻繁にアクセスするファイルをRAMにキャッシュします。/tmpキャッシュを入れるためにこのキャッシュに使用できるRAMの量を減らすのは少し愚かです。これは、頻繁に使用されないファイルがキャッシュで/tmp一般的に使用されるファイルを置き換えるという意味であるためです。
アプリケーションはすでにRAMにアイテムを自由に保存することができ、これはファイルに保存するよりも簡単なことがよくあります。したがって、エントリをtmpファイルに入れると、RAMの利点を享受する可能性はほとんどありません。実際のコンテンツを見ると、/tmpおそらくほとんどソケットとFIFO、または少しのIPCデータになります。 RAMベースのファイルシステムを介してアクセスすることは概念的にはよりきれいですが、実際に違いがあるかどうか疑問です。

この場合、/tmpRAMに実装するのはなぜですか？

これは基本属性の実装を簡素化します/tmp。つまり、終了時に削除されます。
ハードウェアの摩耗を少し減らすことができます。これは、ストレージ用に安価で寿命の限られたフラッシュメモリしかない、または書き込み可能なストレージがまったくない環境（たとえば、組み込みシステム）にとってより重要です。
誤用されないと仮定すると、/tmpRAMを使用すると、現代のハードウェアの膨大なメモリ容量を利用できます。つまり、RAMに必要なものがあるかもしれません。

16MBできるそれだけで十分ですが、プロセスが制御できない場合は問題にならず、/tmp誰でも書くことができるはずです。しかし、プロセスへの書き込み中にパニックが/tmp発生したり、ハードドライブがいっぱいになったり、RAMパーティションが使い果たされたりして、危険な信号がより速く発生した場合、それは良いことではありませんか？

使用しているソフトウェアに自信がある場合は、後者がより適しているため、RAMパーティションを選択できます。/tmp異常な状況（例：）が発生した場合に備えて、まず実際の使用量を確認する必要がありますdu -h /tmp。「通常のしきい値」を設定し、cronジョブを使用してそのしきい値を確認して、しきい値を超えた場合は誰かに警告したり、緊急クリーンアップを実行したりできます。

残念ながら、一部のアプリケーションは、/tmp突然エラーが発生した場合に削除されなかったコンテンツを時々ダンプする可能性がありますが、サーバー（頻繁に終了しない）ではこのコンテンツが無期限に残る可能性があります。誰かがログインして何かを使用し、接続がランダムに閉じられたり中断されたりする場合など、これは非常に無害になる可能性があると思います。

したがって、RAMでない方が/tmp安全です。乱用は長い間目立たないかもしれませんが、これはRAMほど深刻ではないからです。また、問題が発生した場合、ディスクに問題の原因を示す明確な証拠があります。

Answer 1