Man*_*eel 4 filesystems ext4 symlink hard-disk nextcloud
我没有配置我的 Nextcloud（Linux/Nginx/PGsql/PHP）服务器来查找我的旋转硬盘驱动器上安装的文件夹/mnt/HDDfs/，而是 Sym-Linked/var/Nextcloud_Data所以它指向/mnt/HDDfs/Nextcloud_Data然后将我的 Nextcloud 配置指向/var/Nextcloud_Data. 这样，如果我决定更改挂载点的名称，就不必接触数据库，因为我可以简单地编辑符号链接。
一开始觉得是个好主意，但后来我想起我的根/驱动器是一个 SSD，与传统的磁碟相比，它只能承受有限的磨损；即使使用磨损在当今的磁盘上是微不足道的，一遍又一遍地敲击驱动器的特定单元并不是最好的主意。
我要问的是：当程序加载和/或写入带有符号链接的位置时，操作系统是否每次都从源位置加载符号链接，然后跟随它到达真正的目标并在那里执行操作或它是否“缓存”符号链接并直接转换/var/Nextcloud_Data/filename为/mnt/HDDfs/Nextcloud_Data/filename？
Gil*_*il' 11
这很好，原因有很多。
首先，闪存驱动器关注的是写入次数，而不是读取次数。
其次，这种担忧适用于固件较差或驱动程序较差的较旧或较便宜的驱动器，但不适用于现代操作系统上的现代驱动器。现代 SSD 具有足够好的磨损均衡，现代操作系统具有区分覆盖和擦除 ( TRIM ) 的驱动程序，因此在写入次数开始成为问题之前需要很长时间。在这个时代，磁力驱动器通常会因与机械相关的原因而死机，例如错误位置的湿度或灰尘或机械损坏。
读取符号链接可能会根据系统配置更新其访问时间。Linux 默认每天只更新一次文件的访问时间。因此，即使担心写入驱动器的次数，一次写入将是一天，而不是通过符号链接进行一次访问。
内核在其磁盘缓存中保存有关符号链接的信息，就像它从磁盘读取的任何其他信息一样。它没有保留一个写着“重定向到”的缓存，但它维护着一个写着“是一个目标是”的符号链接的缓存。这意味着只要缓存条目仍然存在，它就不会从驱动器中读取。这与访问时间更新的频率无关：这是访问文件的时间的函数，而不是从驱动器传输有关文件的信息的时间。/var/Nextcloud_Data/filename/mnt/HDDfs/Nextcloud_Data/filename/var/Nextcloud_Data/mnt/HDDfs/Nextcloud_Data