我有一台运行 Samba 的 NAS，带有一个 20T ZFS 池，一个 raid1 vdev 和两个旋转的 rust 驱动器。我现在的机器中有 16G RAM。存储用于不断增长的视频片段的永久备份存档。它一次写入，一次读取以进行处理，然后可能进行备份恢复。
我经常将 40GiB 文件发送到此 NAS。我将把千兆网络升级到 10GbE，以使此过程不那么痛苦。但是我怀疑我将受到底层驱动器写入速度的限制。
我的理解是，ZIL 和 SLOG 仅加速同步写入，因此添加 nvme SSD 作为 SLOG 不会影响我的用例，因为我相信 Samba 默认使用异步写入。
我不确定配置 samba 进行同步写入并在 nvme SSD 上添加 SLOG 是否能满足我的需要。我理解如果驱动器发生故障或断电，这会带来数据丢失的风险。这是可以接受的，因为我将文件保留在源机器上足够长的时间，以便在近期数据丢失的情况下重新传输。SSD 的磨损是一个问题，但典型的驱动器有 300 TBW 左右，足以填满我永不删除的 NAS 15 次，或者以目前的数据生成率在 75 年内填满，我可以接受，如果/当 SSD 坏了时，我会买一个新的 SSD。这些都是可以接受的警告。通常我只会尝试进行基准测试，但在目前一切都短缺的情况下，我想提前知道我需要为此购买什么。
我知道我可以向池中添加更多 raid 1 vdev 以获得 raid 10 池，但这太昂贵了，中塔式底盘无法支持那么多驱动器，它会与现有驱动器一起严重过度配置池，并且随着时间的推移会消耗更多的能量来保持所有生锈的驱动器旋转。
除了以 raid 10 的方式向池中添加更多旋转锈蚀之外，我还有哪些选项可以使这个 zfs 池至少 40GiB 的数据实现超过 10Gbps 的写入速度？
答案1
同步写入模式可确保写入立即到达持久位置。使用异步写入时，数据将缓存在 RAM 中，并且写入调用会立即完成。文件系统将安排实际写入到最终位置（硬盘）。
在 ZFS 的情况下，ZIL / SLOG 的作用是充当快速的临时持久存储，允许同步模式，即确保写入客户端的写入是最终的。否则，文件系统需要直接将块写入硬盘，这会使同步模式变慢。
对于您来说，如果您想确保全速写入 40 GB 的数据，那么您应该增加 RAM 大小以覆盖文件的大小。
但是，由于 FS 会立即开始写入硬盘，因此您不需要 40GB 内存即可全速写入。例如，当客户端写入 20GB 数据时，10GB 可能位于 RAM 缓存中，而其余 10GB 已位于硬盘中。
因此，您需要进行一些基准测试来了解需要多少 RAM 才能获得全速写入。
答案2
我理解如果驱动器发生故障或断电，数据可能会丢失。这是可以接受的，因为我会在源机器上保留文件足够长的时间，以便在近期数据丢失的情况下重新传输
如果你可以容忍最多 5 秒的写入丢失，你可以简单地将 ZFS 配置为忽略使用命令同步请求zfs set sync=disabled tank
强制所有写入都经过 SLOG，即使速度非常快，也是绝不比绕过同步请求更快。SLOG 不是传统的写回缓存，它吸收写入并将其转移到较慢的层。相反，它是一种通过临时存储同步写入（和仅有的它们）存储在中间快速存储中。几秒钟后，相同的写入将从主内存传输到主池。在发生崩溃（和恢复）之前，永远不会读取 SLOG。
也就是说，使用单个基于 HDD 的镜像 vdev，你永远无法使 10 Gbs 链路饱和。要以 ~1 GB/s 的速度持续写入，你需要至少raidz2 中的 10 个硬盘或镜像+条带中的 12 个以上硬盘。或者，更好的是，您需要一个全 SSD 池。这甚至在考虑诸如 、 等事情recordsize之前compression。
编辑，澄清 SLOG 工作：
为了最大限度地减少同步写入的延迟，ZFS 使用了所谓的 ZFS 意向日志 (ZIL)。简而言之：每次同步写入到达时，ZFS 都会立即将它们写入名为 ZIL 的临时池区域。这使得写入能够立即返回，让调用应用程序继续。几秒钟后，在事务提交时，写入 ZIL 的任何记录都会回复到主池。这确实不是意味着每次提交时都会读取 ZIL；相反，要写入的数据来自主 DRAM ARC 缓存。换句话说，ZIL 是一种“预记录日志”，可确保要写入的同步数据的快速数据持久性。
这实际上意味着同步写入是重复的：它们被写入两个都进入 ZIL 和主池。进入SLOG（分离日志设备）：专用于仅同步写入- 即：它将主池从 ZIL 流量中解放出来。快速的 SSD SLOG 非常重要，因为 HDD 的同步写入速度非常慢。SLOG 不是您的传统写回缓存，因为：
- 它只吸收同步写入，完全忽略正常写入；
- 它仅复制已缓存在 ARC 中。
这两点结合起来意味着，较大的 SLOG 基本上是浪费，因为它只需要 ZFS 事务最大大小的 3 倍。换句话说，2-4 GB 的 SLOG 在大多数情况下就足够了，更大的 SLOG 仅在特定设置中才有用。
这样的 SLOG 是提供较低随机同步写入延迟的关键，但尽管它可以吸收非常小的顺序同步写入峰值，但这并不是它的主要功能。换句话说，您可以将 ZIL/SLOG 视为 ARC 的持久切片。推论是，您不能指望通过 SLOG 写入数十 GB 并隐藏缓慢的主池速度，因为这意味着您已经有数十 GB 的脏数据在基于 RAM 的 ARC 内部。
设置sync=disabled指示 ZFS 将所有写入（甚至同步写入）视为正常异步写入。这将绕过任何数据 ZIL/SLOG 和如果你能接受 5 秒的数据丢失窗口，那么这是你能实现的更快的设置- 即使与 Optane 或 RAMdrive 等非常快的 SLOG 相比也是如此。它的优点在于sync=disabled它不会禁用 ZFS 自身元数据的同步写入，因此不会使您的文件系统面临风险。这并不意味着您可以轻率使用它：正如多次提到的，您应该确保了解其含义（如果发生崩溃/断电，您可能会丢失最后几秒未同步的数据）。
另一方面，传统的基于 SSD 的写回缓存lvmcache可以bcache（或多或少）有效地使用数百 GB 的 SSD 缓存来掩盖主池延迟/吞吐量 - 特别是因为它们是功能齐全的写回缓存，无需将数据放在主内存中（相反，主内存自己冲洗通过这些 SSD 缓存)。
ZFS 背后的原因是，（大）主系统内存是真正的读/写缓存，而 SLOG 是一种降低随机同步写入延迟的手段。