私がこのディレクトリについて心配する~/.cache理由は2つあります。 SSDには不要な書き込みがたくさんあり、暗号化されたコンテナと外部ドライブ上のファイルに関する情報（画像サムネイルなど）が含まれているためです。
tmpfsに入れてfstab。いっぱいになるまで問題なく実行されます。これにより、一部のプログラムではエラーメッセージが表示されます。
私はファイルが.cache持続してはいけないと思います（tmpfsに似ています/tmp）。これが私がtmpfsを使用する理由です。だからcrontmpfsがいっぱいになると、時間ごとにクリーンアップするために実行されるスクリプトを作成しました。.cache
trackerただし、これによりそのデータベースが見つからないというエラーメッセージが表示されます。
これは、このディレクトリが実際に持続してはいけないのかどうか疑問に思います。に入れるのは良いアイデアですかtmpfs？
ベストアンサー1
あなたに問題があるようです。
はい、キャッシュにトラッカーデータベースが含まれている場合は、それを「クリーンアップ」すると再構築されます（すべてのファイルを厳密にスキャンした後）。だから私はそれではないと思います。すごいアイデア。
根本的な問題は、空き領域を観察しない限られたファイルシステムにソフトウェアを書き込む（結合された）ソフトウェアがあることです。
あなたの考えを聞いて教えてください
私はFedoraが/tmp古いファイルを削除するtmpreaperを使って管理されていたと思います。理論的には、一部のアプリケーション開発者はこのモデルを期待している可能性があります。実際、人々は〜/.cacheに対してこれを実行しないため、次のような結果が発生する可能性があります。一部テストされていない極端は爆発する可能性があります。たとえば、これがls -l --time=atime ~/.cache/trackerかなりの変化を示していることがわかったので、これがうまく機能することを保証することはできませんか？
最も重要なソフトウェアには、ほとんど構成可能な制限があります。しかし、これはあまり良い解決策ではありません。各スペースを個別に構成し、各スペースに固定の空きスペース（またはゼロ）を提供する必要があります。
たとえば、最近の画像やコードを再ダウンロードしないように100Mを許可するなど、Web検索に役立つと思います。 （私は実際にFirefoxの基本的な「自動キャッシュ管理」がファイルシステム自体を埋めるのを防ぐと疑います）。
埋め込まれていないスペースまたは固定スペースが割り当てられていると信じる一部の「ホワイトリスト」ソフトウェア（シンボリックリンクを使用してリダイレクト）に対して別々のtmpfsを持つことができ、他のソフトウェアでスペース不足エラーが発生する可能性があります。既存システム）。
紙
標準のディスクキャッシングを余裕がない場合は、選択したソフトウェアに対してのみキャッシングをサポートするように変更し、他のすべてのソフトウェアは破損制限を実行する必要があることを示唆しています。ここで重要な言葉は「もし」です。
（または：使用する特定のソフトウェアが最も一般的なソフトウェアよりも書く能力がはるかに優れている場合は、おそらくあなたの言葉が正しいでしょう、そしてその特定のソフトウェアを含める必要があります）。
数字を実行します。 SSDは本当に危険にさらされていますか？
さて、Windowsを実行できる最小限のeMMCを備えた低コストのNetbookについて話している場合はそうです。ディスクを監視したい場合がありますスペースソフトウェアを使用し、自分自身を制限して無効にします。この種のランアウェイ（組み合わせ？）ソフトウェアを使用する必要がある場合、tmpfsはディスクキャッシュにいくつかの書き込みを含めるのに役立ちます。ただし、特定のソフトウェアを識別する必要があります。
しかし、一般に「eMMC」ではなく「SSD」（現在128-256GiBで始まる）として販売されているデバイスでは、最も一般的なソフトウェアはまったく問題を引き起こしません。データ、テスト、信頼できるソースなどがサポートされているという一般的な確信が必要な場合は、Googleがあなたの友達です。興味深い記事がたくさんあります。個人的には、使用量をモニターして全体像を得ることができたらと思います。ここに役立つツールがあると思います。
- 私は
tune2fs -l /dev/...与えられたext4ファイルシステムで「一生の書き込み」を見たことがあります。残念ながら、btrfsはこれをサポートしていないようです。 - 実行中のシステムでは、
/sys/block/<dev>/stat512バイトがデバイスに書き込まれた回数を示す7番目の列を表示できます。定期的に終了スクリプトに記録することができるようです。 sudo atopプロセスごとのディスク書き込みはディスクモードで表示できます。たとえば、「d」を押すと、起動後の各プロセスの累積書き込みが表示されます。数秒後に最後の間隔を表示するように変更されます。 問題が発生しました。引き続き累積数を表示するなど、より良い方法があります。
cronでune2fsを使用してスクリプトを実行してログファイルに追加し、1日に1〜4 GBの書き込みを観察しました。私は本当に見たいものよりも高いですが、ドライブの定格書き込み寿命を考えると、私にとっては問題になりません。 10年以上続く必要があり、その時点が過ぎると保証が期限切れになり、とにかく交換する必要があります。保証期間が満了する前にドライブを交換する予定がない場合でも、寿命の評価は保守的に維持する必要があります。テストの結果、ドライブは定格より数倍長く続くことがわかりました。
バックアップしましたか？重要なデータの生存を確実にするためにハードウェア障害がまったく発生しないことに頼る必要はありません。