上面说了那么多理由……iOS 用户默默的看过来....

@baogyq 非常有同感

依旧限速

@PROJECT 应该和段没关系。

@bigfei 同+1

同样限速。没跑 PCDN 。已经投诉了。
而且这个限速还还有白名单，比如到 speedtest 、百度云盘之类的正常。非白名单之外的共享 5Mpbs 。

不要买没经过长期市场考验的 nas 产品。

这种事情不建议做，收益不大风险无上限。

你看看内核日志有没有 io 读写失败相关的报警。

一般布线需要考虑未来 15 年的需求。
奔着支持 40G 或者 100G 去吧。
10G 外网接入估计未来 5 年左右会普及？

罗技 MX Anywhere3 有类似问题：
1 ） intel macbookPro + macos 正常。
2 ） intel macbookPro +win11 正常
3 ） thinkpad x1 鼠标只要 10 多秒不动，下一次移动开始大概率会卡 0.5 秒左右。升级电脑驱动，bios ，鼠标驱动无法解决。后来发现关闭蓝牙节能能解决。但是会导致鼠标连接断开（比如电脑休眠）以后无法重新连接，需要重新配对。

iptables-save 不是只导出规则么？至少应该覆盖默认规则配置文件吧。还是我记错了。

上海电信 CN2 表示丢包率爆炸

@leang521 群晖的 SHR 本质上是 mdadm （就是你前面看到的/dev/mdX ） + lvm （用来组装+划分空间）
现在主要是想办法把/dev/md3 恢复出来。

你手上还有别的 linux 机器不？试试把 sata4 ，sata5 （即现在 raid6 中未使用的 2 块盘）拿到别的机器上：
mdadm --assemble --scan
看看能不能扫到阵列。

@cr3bit
看有没有写入数据了。除了他自己主动写入，剩下的就看群晖自己了。我看他有 2 个 volume ，如果套件都在另外一个上面应该还好......

@leang521
理论上只有 1 ，2 在线的情况下，读取出的数据应该也是正确的。但你这样读取出来的错误的数据，我只能猜测是之前数据就已经不正确了。或者在重建过程中群晖做了别的什么操作导致 RAID6 上 4 块盘的状态并不一致。

从给的数据来看，volume_2 （ 7T 的卷）由 stat1 ，2 ，4 ，5 盘的第 3 个分区组成。
整个操作过程中尝试直接重新使用 4 块盘重新组建 raid ，但系统只使用了 2 块（ 1 ，2 ）。另外两块盘处于 remove 状态。

看了一下阵列并未启用 Bitmap （群晖默认应该是不启用的），也就是现在即便现在你把盘插回去重建，也只会使用 1 ，2 的数据来全量重建 4 ，5 。这种情况下 4 ，5 得到的数据和你现在直接从 1 ，2 上读取的应该是一样由问题的。

还有一种思路就是把 4 ，5 盘单独尝试挂载一下阵列，看看能不能得到正确的数据。


另外不考虑数据问题的话，可以尝试使用以下指令吧 4 ，5 重新加回阵列。
但再次强调，这么做是以 1 ，2 盘的数据重新计算并覆盖 4 ，5 。

mdadm --re-add /dev/md3 /dev/sata4p3
#检查 raid 状态，等待重建完成
mdadm -D /dev/md3

mdadm --re-add /dev/md3 /dev/sata5p3
#检查 raid 状态，等待重建完成
mdadm -D /dev/md3

@bclerdx
电信 2G+联通 1G > 局域网口 2.5G 。

提供一下个人的情况，刚刚把 J4125 换成 N100 。
换之前是电信 1000M+联通 1000M 接入。4 口 2.5G 能满足需求。
但电信近期升级到 2000M ，2.5G 的局域网口就成瓶颈了。
被迫换成 N100 ，3 个 2.5G+ 2 个 10G SFP+。