 | iBugOneV2EX 第 318309 号会员，加入于 2018-05-24 14:35:53 +08:00今日活跃度排名 55 |
iBugOne 最近回复了
114 天前 回复了 darklightzz 创建的主题 问与答 显示器屏幕太亮了，有什么解决方法吗？ |
是 Windows 的话，有个奇技淫巧是打开 HDR 功能，可以让屏幕再暗一点，但对于原生支持 HDR 的屏幕可能效果不佳，尤其是 OLED
142 天前 回复了 youthdou 创建的主题 Linux 为什么清除缓存后，读文件的程序依然运行很快？ |
既然你说了是虚拟机，那么有没有一种可能，你的宿主机把虚拟磁盘文件对应的块*也*给缓存起来了（狗头
212 天前 回复了 Brunuh2Ville2 创建的主题 TypeScript TypeScript 宣布原生移植计划，性能将提升 10 倍？ |
TypeScript! It's MyGO!!!!!
243 天前 回复了 bfhyqy 创建的主题 推广 T 楼抽奖免费送出（顺丰包邮）30 张全新待激活的英国 giffgaff 卡 |
插个楼，试试手气
245 天前 回复了 eric107008 创建的主题 NAS 6+2 盘位的 NAS 放在办公室如何规划存储和应用？ |
@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/>（我还没写完，但最近忙，只能断断续续地偶尔补一点）
同样，在重建的时候，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/>（我还没写完，但最近忙，只能断断续续地偶尔补一点）
249 天前 回复了 eric107008 创建的主题 NAS 6+2 盘位的 NAS 放在办公室如何规划存储和应用？ |
作为一位将楼主提到的方案和技术全部摸过的普通 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 均是我写的，或者我参与编写/校对的）
> 不要纠结太多，不要有“一定要把这个那个的性能和带宽都跑满”的想法，否则因为木桶效应的存在，你总是会陷入不断升级每个部件的循环中（直到所有部件的性能都严重过剩）。
[关于连续读写性能] 由于所有数据最终都是存储在 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 均是我写的，或者我参与编写/校对的）
251 天前 回复了 kleos 创建的主题 信息安全 来自 ipv6 only 的神秘问题，收到无法解析地址的流量 |
有没有可能，你只需要 tcpdump -n 就可以看到 ptr.default 的真实 IP 了，少绕一大个弯呢
257 天前 回复了 shadoworld 创建的主题 宽带症候群 光猫改桥接后改 ip 地址，脑抽改成 192.168.5.255 |
秘密：把电脑的地址改成 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 自动创建的广播路由规则，效果同上。
这里需要假设你的猫能够正常访问 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 自动创建的广播路由规则，效果同上。
278 天前 回复了 MRlaopeng 创建的主题 问与答 使用 zfs 存储池也能对数据库存储的数据进行字节存储? |
不用想了，zfs 没这么离谱的功能，能按 recordsize/volblocksize 进行块级别的去重就不错了
Select Language