@caomingjun ZFS 除了奇偶级别的校验，所有的数据也都有额外的校验（ checksum ，方法是哈希而不是 XOR ，默认算法是 fletcher4 ），所以即使没有 RAID ，ZFS 也能知道哪些数据块是损坏的，并且汇报给上层（虽然应用程序可能就只在 read 的时候得到一个 EIO ，并不知道具体细节），并且整个过程不影响其他完好的数据库。在有 RAID 的情况下，ZFS 就可以利用奇偶校验提供的冗余信息来尝试恢复这些数据。

同样，在重建的时候，ZFS 也会把所有数据都读出来并且利用 checksum 确认完整性，然后只修复损坏的数据，因此重建的失败率也取决于数据量。而硬件 RAID 没有这一层额外的 checksum ，就没法判断数据的完整性了，并且硬件 RAID 并不 content-aware ，所以你的理解是正确的：重建的时候要全盘重建。但至于“只是少数几个扇区上的数据的损坏超出了冗余”，就要看 RAID 的实现了，我没有键过这种情况，不好评价。

关于 RAIDZ 盘数推荐，可以看我博客文章（ 1 楼的链接 [6]）里面的第 5 个引用（标题为 How I Learned to Stop Worrying and Love RAIDZ ），这篇引用里的推荐是至少 5 盘 Z ，6 盘 Z2 ，11 盘 Z3 ，但同时也不要太多盘。

剩下的内容和细节可以阅读 Linux 201 关于 ZFS 的页面：<https://201.ustclug.org/ops/storage/zfs/>（我还没写完，但最近忙，只能断断续续地偶尔补一点）

作为一位将楼主提到的方案和技术全部摸过的普通 V2EX 用户，我的看法是：

> 不要纠结太多，不要有“一定要把这个那个的性能和带宽都跑满”的想法，否则因为木桶效应的存在，你总是会陷入不断升级每个部件的循环中（直到所有部件的性能都严重过剩）。

[关于连续读写性能] 由于所有数据最终都是存储在 HDD 阵列上的，尤其是大量连续读写的数据，因此 HDD 阵列的性能决定了“任意资料”（尤其是冷资料）的读取性能。如果你真的想跑满万兆网络，请增加 HDD 到至少 8 块（假设你使用 RAID-Z2 ，此时有 6 块数据盘，按单盘 200 MB/s 的速度估计，可以达到 1200 MB/s ）。

[关于随机读写性能] 请扔掉 SSD ，你不需要把它利用起来，否则只会起反作用。给你的 NAS 加更多的内存用于 ZFS ARC 。
根据 USTC 镜像站的数据 [1]，对于冷热分明的数据，ZFS ARC 能够提供足够好的命中率，而 L2ARC 仅有不到 1/3 的命中率。结合“ARC 命中率足够高”这一点，根据 Amdahl 定律，考虑到 L2ARC 还会占用 ARC 来维护它自己的 metadata ，盲目使用 L2ARC 并不能带来更好的性能，不如节约下来 SSD 的寿命做点别的，哪怕只是用作系统盘（ rootfs ）。
对于冷数据，我不认为任何文件系统能够处理好这种情况，除非你上全闪（显然钱包不会很开心），没有必要也不应该考虑冷数据随机读取的性能，而 ZFS 由于它的日志式设计，可以将随机写 buffer 起来转换成顺序写 [6]，因此你也没有必要使用 SLOG [7][8]（ NAS 应该不会有 O_SYNC 写入吧）或者考虑任何形式的 SSD 作写缓存的用法。

[关于 ZFS] 对于 NAS 这种场景，你需要适当调节 ZFS 的参数，具体可以参考链接 [1]（镜像站就是一个巨大号的 NAS ，该文章所提及的大部分参数在这里同样适用），减少碎片率和 HDD 的 I/O 次数，以及增加分配给 ARC 的内存量（没错，这个建议归根结底还是“加内存”）。

[关于 LVM] 建议扔了不要用，你已经在用 ZFS 了，没有任何必要使用 LVM 和 LVMCache 。LVMCache 的性能很差（见 [1] 的截图）并且算法很原始 [1]；而 ZFS 的 ARC 是一个非常先进的、自动调节的算法 [2]（只是需要更多内存）。同时 LVMCache 有各种大大小小的坑，尤其是 writeback 模式下 [3]，甚至还会把 GRUB 搞糊涂 [4]，我们为此花费了不少精力去调查研究，并且自己 patch 代码 [4] 解决或者只是绕过这些问题。相信你没有抖 M 到这个程度（

且不说 ZFS 无论如何不应该跑在其他形式的 RAID 或缓存机制上 [5]，有了 ZFS ，你也没有任何必要再在上面套一层 LVMCache （同理，这也会让你失去 ZFS 的一大半高级特性和性能优化）。

[其他]
「如果哪个硬盘坏了，我能有个办法及时知道」→ 你需要的是基于硬盘 SMART 信息的报警功能，请自行调研 smartd （ apt install smartmontools ）的报警功能。
「很多人不推荐 writeback 缓存策略是因为」→ 见上，我有另一批完全不同的理由不推荐 LVMCache 。

[关于更换方案] 个人推荐你换掉那个小的、CPU 性能差、内存容量少的定制 NAS 主机，而是重新搭一个台式机，可以用更好的 CPU （ 7950X / 9950X + X870 / X870E 等，甚至选用带 IPMI 的主板，不过预算可能压不住），配更好的电源和更好的机箱（便宜：半岛铁盒 F20 ；结实牢固、设计合理：分型工艺 Define 7 XL ），这些看似周边的部件反而是一个更可靠的 NAS 的基础。
软件方面我没有任何想法，自己在 Ubuntu 上把（自认为能折腾的）都折腾过了，建议以个人熟悉的软件栈为主。

[结论] 整体性能够用就好，点到为止，不要盲目追求极限。

[最后] 以上全部思考来自我自己搭建和管理服务器的亲身经历。
[最后的最后] 打了这么多字，给点个“感谢”送点铜币吧（暴露了，其实我是来骗铜币的）。祝楼主和其他 V 友春节愉快，阖家欢洛！

[参考资料]
[1]: https://lug.ustc.edu.cn/planet/2024/12/ustc-mirrors-zfs-rebuild/#mirrors4
[2]: https://www.usenix.org/conference/fast-03/arc-self-tuning-low-overhead-replacement-cache
[3]: https://docs.ustclug.org/services/mirrors/4/volumes-old/#ssd
[4]: https://github.com/taoky/grub/commit/85b260baec91aa4f7db85d7592f6be92d549a0ae
[5]: https://serverfault.com/q/545252/450575
[6]: https://ibug.io/p/62 （我的博客）
[7]: https://superuser.com/q/1428707/688600
[8]: https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html
（注：以上链接中 1, 3, 6 均是我写的，或者我参与编写/校对的）

有没有可能，你只需要 tcpdump -n 就可以看到 ptr.default 的真实 IP 了，少绕一大个弯呢🐶

秘密：把电脑的地址改成 192.168.5.1/22 ，注意掩码长度必须是 22 （或者更小，比如 21 ，但没必要）。

这里需要假设你的猫能够正常访问 192.168.5.1 ，否则只能重置它。本操作的关键在于 22 的子网掩码，默认 24 的子网掩码会让操作系统把 5.0 和 5.255 当做网络地址和广播地址（从而不能正常访问），但当你把掩码缩短到 22 之后，网络地址和广播地址就变成了 4.0 和 7.255 ，这时候 5.255 这样的地址就变成了单播地址，可以正常访问了。

对于 Linux：除了上述方法之外，也可以正常设置 192.168.5.1/24 ，然后 [ip route delete broadcast 192.168.5.255 table local] 强制删掉 kernel 自动创建的广播路由规则，效果同上。

不用想了，zfs 没这么离谱的功能，能按 recordsize/volblocksize 进行块级别的去重就不错了

遇到类似问题建议首先通过我们的 GitHub issue 区反馈：< https://github.com/ustclug/discussions >，在其他地方发贴我们是无法及时看到的，但 GitHub issue 是有通知的。

由于 PCDN 猖獗，各大高校镜像站都是恶意流量（大量刷下载）的受害者，因此各家都有一些风控规则，下次遇到的时候可以先尝试 1 楼的方案。

摩尔庄园

9 月 2 号下午开始不行了，联系客服能恢复一会，但还是没法进入订单结算页面，也没法查看历史订单，正在考虑找个旧版美团 app 试试

一股浓浓的 GPT 味道，前后又是重复的车轱辘话，基本没有有效的信息量，还是 1 楼评价得最言简意赅

@MegrezZhu 肌肉记忆：键盘输入 ruh ，第一个选项一般就是“如何”；但是如果不小心打成了 rug ，第一个选项就是“如果”

@wniming #14 除非你的网络结构非常简单（单上游，无分流），否则不推荐 sd-resolved ，只能作为一个最基础的本地 dns 缓存用，没有什么实际意义。我们内部用的是 bind9 （也是学长们留下来的设施，过于高端），普通用户还是推荐 dnsmasq 或者 AdGuard Home 。

@wniming #12 我记串了，50 万条路由表跑挂 sd-nd 是另一台机器，镜像站挂的原因是我们自己的一些操作（删了 pref 32766 和 pref 32767 这两条默认的路由规则）导致 sd-nd 导入路由表的时候 netlink 报错，也就是正常操作情况下不应该遇到的问题。当然暂时也不要用 sd-nd 管理 10 万量级的路由表就是了（ systemd 255 修了这个问题）

@wniming 我把 systemd-networkd 跑挂了是因为我尝试用它管理 50 万条路由表条目，超出了内核 netlink 的某种数字范围；我在自己的机器上用 sd-nd 管理网络，只导入了一个大陆 IP 路由表，4000 多条，就没有任何问题

除了配置文件有点啰嗦之外，我还是很推荐 sd-nd 的，尤其是当你已经在用 netplan 之类的前端的时候

1. 用宝塔
2. 自己都不知道自己配了个啥
3. 管硬盘叫内存

buff 叠满了，这种问题估计没什么人愿意理

@povsister 主要是这种配置不会在没有人改动的情况下自己坏了，所以我们就没配很详细的监控（监控方案是 Telegraf+InfluxDB ，还是很容易加一条配置的，就没有必要折腾一个新的软件了）

@povsister 10 分钟修复是因为我知道什么东西挂了，加上我熟悉 systemd-networkd 的配置。

监控我们有 Grafana ，但是平时不会主动看，也没有配置“流量剧烈下降”这种（没什么意义）的报警，所以光靠监控是不能及时发现的。

我的锅，网络配置没写好，重启 systemd-networkd 之后也没仔细确认网是不是好的，所以才把镜像站搞掉线了

你们要的复盘： https://servers.ustclug.org/2024/06/mirrors-outage-report/

更新疼讯云之类的对象存储可以直接 rclone sync ，不需要自己编写很复杂的脚本