解決策 1:
相対時間を考慮する:
新しいインストール (~2008) を使用している場合は、relatime を使用できます マウントオプション。これは、私が思うに良い妥協案です。この新しいオプションの実装に関する kerneltrap の議論から:
<ブロック引用>「相対 atime は、前の atime が mtime または ctime よりも古い場合にのみ atime を更新します。noatime と同様ですが、ファイルが最後に変更されてからいつ読み取られたかを知る必要がある mutt のようなアプリケーションに役立ちます。」
これにより、atime を必要とするほとんどのアプリケーションは引き続き動作しますが、ディスクの負荷が軽減されます。つまり、これは妥協点です。これは、最近の Ubuntu デスクトップ ディストリビューションのデフォルトです。
ノアタイムとノディラタイムについて:
noatimeに行く場合 ファイルの場合、nodiratime を使用しない理由があるのだろうか noatime に加えて そのため、ディレクトリのアクセス時間も更新していません.
言及されていないatimeを有効にしておくもう1つの理由は、監査目的です。しかし、誰以来 アクセスされたものは保持されず、いつのみ 、おそらく監査証跡にはあまり役に立ちません。
これらのオプションはすべて「man mount 8」にあります。
解決策 2:
一定期間アクセスされていないファイルをセカンダリ ストレージに移動するアプリケーションが存在します。明らかに、彼らには atime が必要です。
それ以外には、特に最近のファイルマネージャーはファイルを開いてプレビューを生成する傾向があり、ディレクトリを閲覧しているときにatimeを変更する傾向があるため、これは（もう）あまり使用されていません。
最近はいつもnotimeでマウントしています。
解決策 3:
これに依存するアプリケーションはほとんどありません。たとえば、Mutt は、フォルダーが最後にアクセスしてから新しいメールを受信したかどうかを判断できません。
通常、私や他の人たちは、notime をマウントするのは良い考えだと思います。
解決策 4:
まだ言及されていない主な欠点は、tmpreaper プロセス (つまり、しばらくアクセスされていない /tmp 内のファイルを削除するプログラム) がある場合、まだ使用中の tmp ファイルを削除できることです。
relatime は noatime よりも優れたオプションです。前回の atime 更新以降にファイルが変更されている場合にのみ、atime を更新します。これには、メール クライアントにとって明らかな利点があります。 tmpreaper の問題はまだ修正されていません (ファイルが /tmp から読み取られても、書き込まれることはありません)。
全体として、欠点は小さく (いくつかの特殊なケースを除いて存在しません)、パフォーマンス上の利点は重要です。