SSDにシンボリックリンクを維持することでSSDをハンマーで叩いていますか？
私のNextcloud（Linux/Nginx/PGsql/PHP）サーバーを設定して、/mnt/HDDfs/にマウントされた回転しているハードドライブ上のフォルダーを探す代わりに、/var/Nextcloud_Dataを指すようにシンボリックリンクし、/mnt/HDDfs/Nextcloud_Dataをポイントし、次にNextcloud構成を/var/Nextcloud_Dataにポイントしました。このようにして、マウントポイントの名前を変更する場合でも、シンボリックリンクを編集するだけでよいので、DBに触れる必要はありません。
最初は素晴らしいアイデアのように思えましたが、私のルート/ドライブはSSDであることを思い出しました。SSDは、従来の磁気プラッターと比較して限られた摩耗にしか耐えることができません。今日のディスクでは使用による摩耗がごくわずかであっても、ドライブの特定のセルを何度もハンマーで打つことは、必ずしも最良のアイデアではありません。
私が求めているのは、プログラムがシンボリックリンクを含む場所にロードおよび/または書き込みを行うとき、OSはソースの場所から毎回シンボリックリンクをロードし、それを実際のターゲットまでたどってそこでアクションを実行するか、またはシンボリックリンクを「キャッシュ」し、/var/Nextcloud_Data/filenameを/mnt/HDDfs/Nextcloud_Data/filenameに直接変換しますか？
追加情報：
- オペレーティングシステム：すべての最新のパッチとアップグレードを含むUbuntu Server 18.04LTS。
- ディスクドライブ：SATAおよびPCIe M.2（Samsung 960 EVO）SSDを介して接続されたWDREDハードディスク。
- ファイルシステム：両方のドライブは、Ext4ファイルシステムでフォーマットされたGPTです。
- マザーボード：Asus Z170-Deluxe（デスクトップボード）
多くの理由で、それは問題ありません。
まず、フラッシュドライブの問題は、読み取り数ではなく書き込み数です。
第2に、この懸念は、ファームウェアまたはドライバーが貧弱な古いまたは安価なドライブに当てはまりますが、最新のオペレーティングシステム上の最新のドライブには当てはまりません。最新のSSDには十分なウェアレベリングがあり、最新のOSには上書きと消去を区別するドライバーがあります（ [〜＃〜] trim [〜＃〜] ）ので、書き込みの数が始まるまでに非常に長い時間がかかります心配になる。この年齢では、磁気ドライブは、間違った場所の湿度やほこり、または機械的損傷などの機械的関連の理由で死んでいることがよくあります。
シンボリックリンクを読み取ると、システム構成によってはアクセス時間が更新される場合があります。 Linuxのデフォルトでは、ファイルのアクセス時間は1日に1回のみ更新されます 。したがって、ドライブへの書き込み数に懸念があったとしても、シンボリックリンクを介した1回のアクセスではなく、1回の書き込みが1日になります。
カーネルは、シンボリックリンクに関する情報を、ディスクから読み取る他の情報と同様にディスクキャッシュに保持します。 「/var/Nextcloud_Data/filenameは/mnt/HDDfs/Nextcloud_Data/filenameにリダイレクトします」というキャッシュは保持しませんが、「/var/Nextcloud_Dataはターゲットが/mnt/HDDfs/Nextcloud_Dataであるシンボリックリンクです」というキャッシュを保持します。 。これは、キャッシュエントリがまだ存在している限り、ドライブから読み取られないことを意味します。これは、アクセス時間の更新頻度には影響しません。これは、ファイルがアクセスされたときの関数であり、ファイルに関する情報がドライブから転送されたときではありません。