163 天前 回复了 darklightzz 创建的主题 问与答 显示器屏幕太亮了，有什么解决方法吗？ |
是 Windows 的话，有个奇技淫巧是打开 HDR 功能，可以让屏幕再暗一点，但对于原生支持 HDR 的屏幕可能效果不佳，尤其是 OLED
191 天前 回复了 youthdou 创建的主题 Linux 为什么清除缓存后，读文件的程序依然运行很快？ |
既然你说了是虚拟机，那么有没有一种可能，你的宿主机把虚拟磁盘文件对应的块*也*给缓存起来了（狗头
261 天前 回复了 Brunuh2Ville2 创建的主题 TypeScript TypeScript 宣布原生移植计划，性能将提升 10 倍？ |
TypeScript! It's MyGO!!!!!
292 天前 回复了 bfhyqy 创建的主题 推广 T 楼抽奖免费送出（顺丰包邮）30 张全新待激活的英国 giffgaff 卡 |
插个楼，试试手气
294 天前 回复了 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/>（我还没写完，但最近忙，只能断断续续地偶尔补一点）
298 天前 回复了 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 均是我写的，或者我参与编写/校对的）
299 天前 回复了 kleos 创建的主题 信息安全 来自 ipv6 only 的神秘问题，收到无法解析地址的流量 |
有没有可能，你只需要 tcpdump -n 就可以看到 ptr.default 的真实 IP 了，少绕一大个弯呢
306 天前 回复了 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 自动创建的广播路由规则，效果同上。
327 天前 回复了 MRlaopeng 创建的主题 问与答 使用 zfs 存储池也能对数据库存储的数据进行字节存储? |
不用想了，zfs 没这么离谱的功能，能按 recordsize/volblocksize 进行块级别的去重就不错了
2024-11-25 18:14:48 +08:00 回复了 clid 创建的主题 Linux 中科大源 wget 报错 |
遇到类似问题建议首先通过我们的 GitHub issue 区反馈：< https://github.com/ustclug/discussions >，在其他地方发贴我们是无法及时看到的，但 GitHub issue 是有通知的。
由于 PCDN 猖獗，各大高校镜像站都是恶意流量（大量刷下载）的受害者，因此各家都有一些风控规则，下次遇到的时候可以先尝试 1 楼的方案。
由于 PCDN 猖獗，各大高校镜像站都是恶意流量（大量刷下载）的受害者，因此各家都有一些风控规则，下次遇到的时候可以先尝试 1 楼的方案。
2024-10-05 16:32:54 +08:00 回复了 revival83 创建的主题 游戏 我又来求游戏啦，求推荐个手游或者页游，画面可爱点不氪金能一直长玩儿的 |
摩尔庄园
2024-09-04 12:04:23 +08:00 回复了 zictos 创建的主题 Android root 过或类原生的安卓系统最近还能使用美团或美团外卖 app 吗？ |
9 月 2 号下午开始不行了，联系客服能恢复一会，但还是没法进入订单结算页面，也没法查看历史订单，正在考虑找个旧版美团 app 试试
2024-07-30 05:39:23 +08:00 回复了 Tarlor 创建的主题 分享发现 应对 CC 攻击的最佳实践：使用 CDN 和自动化 IP 封禁 |
一股浓浓的 GPT 味道，前后又是重复的车轱辘话，基本没有有效的信息量，还是 1 楼评价得最言简意赅
2024-07-02 04:19:25 +08:00 回复了 89adc64 创建的主题 宽带症候群 如果度过家里两个月没宽带(Wi-Fi)的时间。 |
@MegrezZhu 肌肉记忆：键盘输入 ruh ，第一个选项一般就是“如何”；但是如果不小心打成了 rug ，第一个选项就是“如果”
2024-06-23 14:20:56 +08:00 回复了 wniming 创建的主题 Linux fedora 40 使用 NetworkManager 创建的网桥无法把配置给它的网卡关联起来，这个问题有 v 友遇到过吗？ |
@wniming #14 除非你的网络结构非常简单（单上游，无分流），否则不推荐 sd-resolved ，只能作为一个最基础的本地 dns 缓存用，没有什么实际意义。我们内部用的是 bind9 （也是学长们留下来的设施，过于高端），普通用户还是推荐 dnsmasq 或者 AdGuard Home 。
2024-06-22 21:36:59 +08:00 回复了 wniming 创建的主题 Linux fedora 40 使用 NetworkManager 创建的网桥无法把配置给它的网卡关联起来，这个问题有 v 友遇到过吗？ |
@wniming #12 我记串了，50 万条路由表跑挂 sd-nd 是另一台机器，镜像站挂的原因是我们自己的一些操作（删了 pref 32766 和 pref 32767 这两条默认的路由规则）导致 sd-nd 导入路由表的时候 netlink 报错，也就是正常操作情况下不应该遇到的问题。当然暂时也不要用 sd-nd 管理 10 万量级的路由表就是了（ systemd 255 修了这个问题）
2024-06-22 21:15:40 +08:00 回复了 wniming 创建的主题 Linux fedora 40 使用 NetworkManager 创建的网桥无法把配置给它的网卡关联起来，这个问题有 v 友遇到过吗？ |
@wniming 我把 systemd-networkd 跑挂了是因为我尝试用它管理 50 万条路由表条目，超出了内核 netlink 的某种数字范围；我在自己的机器上用 sd-nd 管理网络，只导入了一个大陆 IP 路由表，4000 多条，就没有任何问题
除了配置文件有点嗦之外，我还是很推荐 sd-nd 的，尤其是当你已经在用 netplan 之类的前端的时候
除了配置文件有点嗦之外，我还是很推荐 sd-nd 的，尤其是当你已经在用 netplan 之类的前端的时候
2024-06-12 16:50:16 +08:00 回复了 zzztongxue 创建的主题 数据库 服务器硬盘空间马上就要被数据库吃满(100 多 G)，该怎么迁移呢？求助求助 |
Select Language