Nextcloud（Linux / Nginx / PGsql / PHP）サーバーがマウントされたローテーションハードドライブ上のフォルダを見つけるように設定するのではなく、そのフォルダへの/mnt/HDDfs/シンボリックリンクを作成してから、Nextcloud設定をそのフォルダとして指定しました。これにより、マウントポイントの名前を変更することにした場合は、単純にシンボリックリンクを編集できるため、データベースに触れる必要はありません。/var/Nextcloud_Data/mnt/HDDfs/Nextcloud_Data/var/Nextcloud_Data
最初は良い考えのようでしたが、私のルート/ドライブは、従来のディスクに比べて限られた摩耗に耐えることができるSSDであることを思い出しました。今日のディスクもドライブの特定のセルを繰り返し叩いても摩耗がほとんど発生しません。最善のアイデアでもありません。
私が尋ねるのは、プログラムがシンボリックリンクのある場所にロードおよび/または書き込むときに、オペレーティングシステムが毎回ソースの場所からシンボリックリンクをロードし、それを実際のターゲットに従うことでアクションを実行することです。それともシンボリックリンクを「キャッシュ」して直接/var/Nextcloud_Data/filename変換しますか/mnt/HDDfs/Nextcloud_Data/filename？
追加情報：
- オペレーティングシステム：すべての最新のパッチとアップグレードを含むUbuntu Server 18.04 LTS。
- ディスクドライブ：WD REDハードドライブとSATAを介して接続されたPCIe M.2（Samsung 960 EVO）SSD。
- ファイルシステム：両方のドライブはGPT形式です。外部4ファイルシステム
- マザーボード：ASUS Z170-Deluxe（デスクトップマザーボード）
ベストアンサー1
大丈夫です。理由は多いです。
まず、フラッシュドライブは、読み出し回数ではなく書き込み回数に焦点を当てている。
第二に、この問題は、ファームウェアやドライバが悪い古いまたは安価なドライブに適用されますが、最新のオペレーティングシステムの最新のドライブには適用されません。最新のSSDには十分なウェアレベリングがあり、最新のオペレーティングシステムには上書きと削除を区別するドライバがあります（打つ）したがって、書き込み回数に注意を払い始めるのに長い時間がかかります。この時期には、誤った位置の湿気やほこり、機械的損傷などの機械的関連の理由で磁気ドライブが故障することがよくあります。
システム構成によっては、シンボリックリンクを読むとアクセス時間が更新されることがあります。デフォルトでは、Linuxは1日1回だけファイルアクセス時間を更新します。。したがって、ドライブへの書き込み回数が心配されても、シンボリックリンクを介した1回のアクセスとは異なり、1回の書き込みは1日になります。
カーネルは、ディスクから読み取られた他の情報と同様に、ディスクキャッシュにシンボリックリンクに関する情報を保持します。 「リダイレクト先」というキャッシュは保持しませんが、「対象のシンボリックリンク」というキャッシュは保持します。これは、キャッシュエントリがまだ存在する限り、ドライブから読み取ることができないことを意味します。これは、アクセス時間が更新される頻度とは何の関係もない。これは、ドライブがファイルに関する情報を転送するのにかかる時間ではなく、ファイルにアクセスするのにかかる時間の関数です。/var/Nextcloud_Data/filename/mnt/HDDfs/Nextcloud_Data/filename/var/Nextcloud_Data/mnt/HDDfs/Nextcloud_Data