@cappuccilo #11
6500pro 做主 mesh 节点，AP 模式上连 RB5009,6500pro 自己的 IP 获取不知道是什么方式，在 ROS dhcp lease 里看不到他的 IP ，但是 ros 是可以给子 mesh 设备（ AX3000T,AX6000 等）分配 ip,目前固件 bug 是，我只要重启 rb5009 ，或者 rb5009 掉线之后，6500pro 自己就会拿不到 ip ，他会给自己分配自己的 192.168.31.X 的内网 ip ，rb5009 就连上之后也不会恢复，就算你把 6500pro 断电了再启动也不会恢复，米家显示 6500pro 掉线，但是子 mesh 没问题，这时候你要么出厂设置重置 6500pro 或者用电脑修改静态成 192.168.31.X ，IP 段连上去在网页端先改成路由模式再改成 AP 模式才行。这 bug 反馈了不知道米家团队会不会修。

6500pro 不做主 mesh 节点的话怎么好像不能用中枢网关吧，6500pro 做主路由 AP 模式 mesh 我这边用下来有 bug ，糟心死了

1.网管交换机对端口进行限速
2.威联通里使用 TC 命令进行限速
3.威联通是双网口话，windows 加张网卡。其中一个网口和 windows 机器新网卡直连，两边配置静态 IP 专门跑数据
我想到就这些

看中中枢功能买的，感觉没这个需求可以直接 pass

这个问题是不是就和问汽车里，不同厂商发动机不能互换，或者统一规格的一样道理

玩玩大饼以太现货其实挺稳的，空气币慎重...
麻烦的是赚的钱如何没风险的出金....
币圈合约其实是门槛很低的交易对了..再里面小资金练练手做好了，后面去再去做 FX\期货\股票也挺好的
合约拿来赌大小的话，去玩上面三个一样会倾家荡产和杠杆倍数没关系，股票杠杆低，想暴富赌狗最后还不还是去借钱梭哈？

我也中招了，我不过我确实跑了 pcdn 哈哈，不给我恢复的话，我直接销户，然后用另一个手机号（非同一人下）直接重新装宽带，不知道行不行

江苏电信坐标 0512 ，去年 11 月份电信透过我认识的装维师傅非正式的问过我大流量的情况（还挺客气的，就说后端看到我流量一直很大），我把相关信息给认识的营业厅片区经理了，后续没有再问过，之后过几天我就被切到 vBras 了，可能和 Bras 切到 vBras 流程中，局端看了一下我的流量很大所以就问了一下，之前是一直没提过这个事情。

rb5009
吐槽一下，过了一年多，container 还是一堆 bug ，勉强能用，而且 1g ram 有点不够用，拉脱维亚小厂能不能再优化优化 bug

越活越孤独，不想与人交流，心态又很差，可能是因为各方面混的都不好，又心有不甘，而且越来越对很多事情麻木，到现在还单身，感觉自己就是别人写好的脚本，遇到什么事情都只会用同样的方法执行

电子榨菜

搭楼问下各位大佬，有从 I5 12400 换到 7302 的吗，目前我 PVE all in boom ,i5 12400 的 average load 1 5 15min 常年 10-15 左右，并且在 unraid 做校验的时候，windows VM 就会明显卡顿（ windows 系统盘不是被校验的 SSD ，非磁盘 IO 瓶颈），12400 的 CPU 单核看跑分快是 7302 的两倍了，不知道目前这种情况换到 7302 是否会有改善,而且 epyc 还有 pcie 通道和大内存的优势，7302 不行的话有必要换更强的 epyc 系列吗

动力就是为了有一天能让自己不不用上班也能过上正常的生活
每次被领导传达压力的时候这种动力越发强大

蹲一个，我也对 7d12 感兴趣

chia 又吃 CPU 又吃硬盘的
不然也不会那么多 epyc 洋垃圾流出来了

网件的固件确实不咋地，R8000 固件升级还故意给你降速，太恶心了
如果不能刷梅林或者其他系统感觉真不行

他工作是不是就是天天到点推特发点狗狗币消息，坐庄出货
如果这种层面也算的话确实很拼

@oldfriend 确实，如果不在意外观噪音重量占地面积和 4U 机箱的暴力扇，服务器下架或者是 chia 矿机的 4U 机箱是最优解了，相对很低的价格就能拿到带背板的 24/36 盘位配置，这比起很多 4-8 盘位的 DIY NAS 机箱确实有优势

这边更新一下处理结果，回去之后在 ssh shell 中使用 reboot 无法关机，使用 reboot -nf 强制重启后无法重启系统，因为是 all in boom 机器，接上显示器后显示系统启动卡在 zfs 文件系统 rpool 加载的过程中，内核识别到了 rpool 并且进行加载，出现了一连串错误没有办法继续下去，每个 40s 刷新一下进度但是报错依旧，基本就是卡在系统的启动阶段，随将 PVE 系统更换为传统的 LVM 逻辑区的安装方式，导入 U 盘引导的 unraid 存储底层虚拟机后再重新将各虚拟机的备份导入，到目前为止系统稳定没有出现报错，后续继续观察是否会有类似故障出现

另外我只能分析出是某些原因导致（不清楚是硬件 /软件 /不过可以确定和 ZFS 有关）原因导致的系统日志进程报错，并且产生了大量 systemd-journald.service 子进程，HTOP 中看为上千个左右，并且为表示进程状态为 "Disk Sleep"，大量 systemd-journald.service 进程造成了 DISK IO 出现无读写无负载但是 IO some 和 IO Full 100%卡死的状态，只是不知道这是原因还是硬件报错以后造成的后果

PVE 系统日志报错情况，显示 systemd-journald.service: Watchdog timeout 看门狗超时
Jun 05 06:37:11 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 07:18:01 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 07:47:11 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 08:17:51 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 08:48:01 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 09:17:11 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 09:47:51 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 10:18:01 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
很多都是一样的....

systemctl status systemd-journald.service 结果
● systemd-journald.service - Journal Service
Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
Active: deactivating (final-sigterm) (Result: timeout) since Mon 2023-06-05 20:47:11 CST; 3 days ago
TriggeredBy: ● systemd-journald-dev-log.socket
● systemd-journald.socket
● systemd-journald-audit.socket
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 774005 (systemd-journal)
Tasks: 673 (limit: 76751)
Memory: 750.2M
CPU: 17ms
CGroup: /system.slice/systemd-journald.service
├─595309 /lib/systemd/systemd-journald
├─623455 /lib/systemd/systemd-journald
├─630728 /lib/systemd/systemd-journald
├─638521 /lib/systemd/systemd-journald
├─646418 /lib/systemd/systemd-journald
├─653880 /lib/systemd/systemd-journald
├─660401 /lib/systemd/systemd-journald
├─665886 /lib/systemd/systemd-journald
├─671968 /lib/systemd/systemd-journald
├─676206 /lib/systemd/systemd-journald
├─678308 /lib/systemd/systemd-journald
├─680379 /lib/systemd/systemd-journald
├─682449 /lib/systemd/systemd-journald
├─684574 /lib/systemd/systemd-journald
├─686661 /lib/systemd/systemd-journald
├─688812 /lib/systemd/systemd-journald
├─690917 /lib/systemd/systemd-journald
├─693026 /lib/systemd/systemd-journald
├─695087 /lib/systemd/systemd-journald
├─697191 /lib/systemd/systemd-journald
├─699286 /lib/systemd/systemd-journald
├─701796 /lib/systemd/systemd-journald
非常长下面全是 /lib/systemd/systemd-journald 子进程

重装前顺便跑了 memtest ，没有跑了一晚上没有发现问题...所以目前只能怀疑 ZFS 加我的硬件造成了系统崩溃，因为已经不使用 ZFS.加上本人也不是 linux 专业，所以也无法深究原因了。
系统备份方面最后也还是使用了传统的 dd 备份整个分区到另一硬盘的方式，并且目前个人感觉家用环境 PVE 宿主机系统备份意义貌似也不是很大，因为也不需要严格保证服务不中断，把所有的虚拟机进行备份之后即使宿主机系统出现故障，重装 PVE 后把所有的虚拟机通过之前的备份就可以快速导入。所以之前 pve 系统安装时使用 zfs mirror 仅仅是看起来很美好，最后发现 zpool 反而是最容易出问题的