请注意，硬链接有一些限制：

• 不能对目录创建硬链接，只能对文件创建。
• 硬链接必须在同一文件系统中创建。
• 当您删除源文件时，硬链接仍然保持对文件内容的访问，因为硬链接和源文件本质上是文件系统中相同文件内容的不同入口点。

我们可以通过 find + ln 来批量创建硬链接。要结合使用 find 和 ln 命令来为给定目录中的每个文件在另一个目录中创建硬链接，可以通过管道（pipe）将 find 命令的输出传递给 xargs 命令，然后使用 ln 创建硬链接。这种方法可以高效地处理大量文件和复杂的文件名。

以下是具体的步骤和命令示例：

1. 使用 find 查找文件：首先，使用 find 命令来查找您想要链接的所有文件。确保只选取文件，不包括目录。

2. 将 find 的输出传递给 ln 命令：通过 xargs 将 find 命令的输出作为 ln 命令的输入。

这是一个具体的命令示例：

1

find /path/to/source-directory -type f -exec ln {} /path/to/destination-directory/ \;

这个命令解释如下：

• find /path/to/source-directory：在 /path/to/source-directory 目录下查找文件。
• -type f：确保只选取文件（file），不包括目录。
• -exec ln {} /path/to/destination-directory/ \;：对于 find 命令找到的每个文件，执行 ln 命令创建硬链接。其中 {} 是一个占位符，代表 find 命令找到的每个文件的路径。

这个命令会在 /path/to/destination-directory/ 目录下为源目录中的每个文件创建一个硬链接。请确保目标目录已经存在，因为 ln 命令不会自动创建目录。同时，由于硬链接的限制，源文件和目标目录必须位于同一文件系统内。

之前我写过一篇文章来吐槽 Nextcloud 的性能问题。当时我是尝试在群晖上试用 Nextcloud。考虑到我使用的群晖服务器的 CPU 性能比价差，因此我尝试在 Unraid 上部署 Nextcloud。但是性能差的问题仍然没有改观。不过近期在 Unraid 发布了 6.12.0 版本以后这个问题得到了很大的改观。

1 问题分析

问题出在 shfs 这个进程上。在 Unraid 中，这个进程负责将分散在各个 Disk 上的文件夹内容聚合成一个统一的目录库，这意味着如果我们要访问任何文件都需要通过 shfs 来查找文件，这也使得 shfs 成文高吞吐率场景下的一个性能瓶颈。之前我经常可以看到 shfs 的 CPU 占用飙升到 100% 甚至 200%。在新版的 Unraid 中提供了 exclusive access 的特性。 Exclusive 的是排他性，独占的意思。Exclusive Access 是指固定将一个目录放在一个 Disk 中，这样我们在访问这个目录下的文件时，就不需要通过 shfs 来检索目录，而是可以直接访问磁盘上的目录系统，从而降低开销。

另一方面，Exclusive 也意味着这个目录无法有效的利用磁盘阵列提供的存储池，而只能利用单磁盘空间。因此，Nextcloud 的数据文件夹是不能使用 Exclusive Access 的。不过好在数据文件的访问其实并不是主要瓶颈，造成 Nextcluod 卡顿的主要原因在对容器挂载的配置文件（也就是 appdata）里面的众多小文件的高频读写。

另一个需要指出的是，在 Unraid 中，尽管缓存有多个 SSD，但是这些 SSD 会预先通过 Raid 机制聚合成一个统一的缓存磁盘，对于 Shfs 来说这个缓存池就是一个单一的磁盘，因此对缓存池的访问可以启用 Exclusive Access

2 如何使用

要是用 Exclusive Access，首先需要再 Settings --> Global Share Settings 下打开（如下图，将 Permit exclusive shares 设置为 yes）。

但是在共享目录使用时，Exclusive Access 的含义是比较模糊的。因为 Share 的管理界面并不会提供一个可以由用户可以直接控制的选项来为具体的 Share 开启 Exclusive Access。事实上，Exclusive Access 是否会起作用是系统根据目录的状态来自动确定的。如前文所述，Exclusive Access 作用的前提是数据只位于一个磁盘中。因此，在 Permit exclusive shares 启用的前提下，如果某个 Share 的文件只可能位于一个磁盘中，那么 Exclusive Access 将自动启用。

要实现 Share 的文件只属于一个磁盘中，需要满足一下条件：

1. Share 只启用了一个 Storage，没有 Secondary Storage
2. 如果 Share 是存储在 Array 中的，在设置 Include disks 时只能选择一个磁盘；
3. 如果是事先已经存在的目录，那么在满足上两条的情况下，还需要通过适当的 Mover 动作，将数据迁移到单一磁盘中。（注意如果之前 Share 是存在多个磁盘中时，做前两条修改，并不会自动将数据迁移到目标磁盘）

在本文的场景中，我们需要在 appdata 这个共享目录上启用 Exclusive Access，就可能需要进行必要的 Mover 操作。如果你看到 appdata 的 Share settings 页面中显示了如下 Exclusive access: no 的文字，进行如下操作：

1. 出现这个状态，说明你的 appdata 并不完全位于缓存中，有一部分是位于阵列中的，此时我们需要让 Mover 将数据从阵列中移动到缓存中。注意：
   1. 如果在现在的状态下，你的 appdata 是 Cache only 的，但是你仍然看到 Exclusive access: no，这是因为曾经某个时刻你为 appdata 设置了阵列存储的选项（以老版本的术语来说，就是 use cache 不是 only，而是 yes 和prefer 的选项），那么在那个时间段内，shfs 可能会将数据文件调度到阵列上。此时即便你讲 appdata 设置为 cache only，Mover 也不会自动将文件从阵列迁移到缓存。修改共享目录的这些相关设置只会影响新文件，而不会直接影响已有文件。
   2. 在上面这种情况下，你需要首先恢复缓存-阵列两级缓存架构，然后将 Mover 行为设置为 prefer cache（在 6.12,0 的属于下，是将 Mover action 设置为 Array -> Cache。然后运行 Mover 完毕。这时 Mover 会将还停留在阵列上文件移动到缓存（当然前提是的缓存的空间要够）。
   3. 完成上面的操作之后，我们再将 appdata 设置为 cache only 的形式（Primiary Storage 为缓存，无 Secondary Storage），这时我们应该能够看到 Exclusive access 变成了 yes。

3 结语

上面的这套操作，能够极大改善 Nextcloud 在 Unraid 上的表现。其他的应用也会有很大的改观（例如 Jellyfin 的打开和搜索速度会有质的提升）。

最近在 Unraid 升级 6.12.x 版本以后会偶发性的产生一个 Bug，其表现为 Unraid 网页无法打开（这里是指访问 Unraid IP 地址无法访问 Web 管理界面）。这个问题实际上是由于 Unraid 上的 Nginx 服务失去响应导致的。这种情况下我们只需要干掉 Nginx 进程并重启就可以了。

首先通过 ps -aux | grep nginx 找到 Nginx 主进程的 PID，然后通过 kill -9 <PID> 干掉进程。要再次启动 Nginx，可以运行

1
2

cd /etc/rc.d/
./rc.nginx start

注意通过 ./rc.nginx restart 在正常情况下可以重启 Nginx 服务，但是在 Nginx 处于无法响应的状态时，这个脚本无法杀死 Nginx 进程，必须要手动终止。