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

玩玩大饼以太现货其实挺稳的，空气币慎重...
麻烦的是赚的钱如何没风险的出金....
币圈合约其实是门槛很低的交易对了..再里面小资金练练手做好了，后面去再去做 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 反而是最容易出问题的

目前用下来还是 NASTOOL 最合适，其实就自动刮削识别度来说 NASTOOL 没比 TMM 好多少，NASTOOL 主要是支持硬链接，硬链接过去的文件名很规范，然后硬链接也可以解决保种的问题，很适合各种其他应用去读取使用(jellyfin/plex/kodi)等

@anguliuyun hdmi 输出不好意思不太清楚，因为我是 12 代使用的是 SR-IOV 虚拟化，是没有 HDMI 输出的，所以我是通过 parsec/moon light 这种串流的形式远程使用，因为我确实也不需要 hdmi 输出所以没有特地研究过

@dode 但是不可避免的总会进行读写，windows 使用还是比较频繁的，安卓模拟器使用总会进行大量的读写。目前决定 win11 存储由 unraid 来提供，zpool 尽量不去碰了。

@sNullp PVE 的 ZFS pool 默认是不开 dedup 的吧，内存不够确实会这样，我刚开始折腾才发现 PVE 的 ZFS 非常坑，默认 L2 ARC 设置的是一半内存，开 VM 直通硬件就容易出现过内存不够机器跑 4-5 天固定直接 ZFS 直接卡死，后面限制过了使用 4G ，就稳定了好久，然后最近又莫名其妙发病了。