noatimeでファイルシステムをマウントすることの欠点？

ファイルにアクセスするたびにすべてのファイルを更新するのは無駄です。

noatimeオプションを使用してファイルシステムをマウントすることの難点は何ですか。どのようなアプリケーション/サーバーがアクセス時間に依存していますか？

relatimeを検討してください：

新しいインストール（〜2008）がある場合は、relatimeマウントオプションを使用できます。これは、私が思うに良い妥協です。この新しいオプションの実装に関するkerneltrapの議論から：

「相対atimeは、前のatimeがmtimeまたはctimeより古い場合にのみatimeを更新します。noatimeと同様ですが、ファイルが最後に変更されてから読み取られたときを知る必要があるmuttなどのアプリケーションに役立ちます。」

これにより、atimeを必要とするほとんどのアプリケーションは引き続き機能しますが、ディスクの負荷は軽減されます。これは、最近のUbuntuデスクトップディストリビューションのデフォルトです。

noatimeとnodiratimeについて：

あなたがしようとしている場合にnoatimeファイルに使用しない理由がある場合、私は疑問に思うnodiratimeのに加えて、noatimeオプションあなたが同様のディレクトリにアクセス時刻を更新されないように。

言及されていないatimeを有効にしておくもう1つの理由は、監査のためです。以来、しかし、誰にアクセス、それが維持されないとだけとき、それはおそらく、監査証跡のためにその有用ではありません。

これらのオプションはすべて「man mount 8」にあります。

一定期間アクセスされていないファイルをセカンダリストレージに移動するアプリケーションが存在します。明らかに、彼らはatimeを必要とします。

それ以外は、特にファイルマネージャがファイルを開いてプレビューを生成する傾向があるため、ディレクトリの閲覧中にatimeを変更する傾向があるため、これは（もう）あまり使用されていません。

最近はいつもnoatimeでマウントしています。

これに依存するアプリケーションはほとんどありません。たとえば、Muttは、最後にアクセスしてからフォルダーが新しいメールを受信したかどうかを判断できません。

一般的に私と他の人は、noatimeをマウントすることは良い考えだと思います。

まだ言及されていない主な欠点は、tmpreaperプロセス（つまり、しばらくアクセスされていない/ tmp内のファイルを削除するプログラム）がある場合、まだ使用中のtmpファイルが削除される可能性があることです。

reatimeはnoatimeよりも優れたオプションです。最後のatime更新以降にファイルが変更された場合にのみ、atimeを更新します。これにはメールクライアントにとって明らかな利点があります。それでもtmpreaperの問題は解決しません（ファイルは、書き込まれることなく何年も/ tmpから読み取られる可能性があります）。

全体的に、デメリットは軽微で（いくつかの特別な場合を除いて存在しません）、パフォーマンス上のメリットは非常に大きくなります。