
Mac 有 IPv6 地址却 ping 不通任何公网 IPv6。之前一直正常,某天突然全断,重启路由器也没用。最终定位是 iStoreOS 的 NDP Relay 模式不稳定,改一行配置从 relay 切到 server 就修好了。这篇记录了逐层排查到根因的完整过程。


Mac 有 IPv6 地址却 ping 不通任何公网 IPv6。之前一直正常,某天突然全断,重启路由器也没用。最终定位是 iStoreOS 的 NDP Relay 模式不稳定,改一行配置从 relay 切到 server 就修好了。这篇记录了逐层排查到根因的完整过程。
AWS 不提供 Graviton 架构的 Windows AMI,但这不代表 Graviton 跑不了 Windows。本文记录如何用开源项目 bin456789/reinstall 的一键 DD 脚本,把一台运行 Amazon Linux 2023 的 t4g 实例原地重装成 Windows 11 Pro ARM64。


新 Mac 到手后,我习惯先做一次系统化检测:硬件信息、SSD 健康、接口状态、安全配置、系统稳定性都过一遍。这样后面如果遇到异常,可以知道是机器本身的问题,还是后续使用环境造成的。
EBS 卷仅支持单向扩容,不允许直接缩容。对于非 Windows 系统所在的数据卷,可以直接创建一个新的小容量 EBS 卷挂载到实例后进行文件级别的复制(如 robocopy)。而对于 Windows 系统所在的根卷,或者数据卷中存在持续读写的文件(例如 SQL Server 的数据库),就需要关机后进行冷处理。
本文使用 Windows Server 2012 R2,原始根卷和数据卷各 100GB gp3,目标缩容到各 50GB gp3。
在开始操作前请务必对实例创建 AMI 进行备份,并在测试环境中启动实例进行测试,再应用到生产环境。复制根卷需要停止实例,建议在业务低谷期进行。停止实例会导致实例存储数据丢失以及自动分配的公网 IP(非 EIP)丢失。
Codex CLI 的 read-only、workspace-write 和 danger-full-access 是策略层配置,真正的隔离由操作系统后端执行。本文把源码级分析和常见 Linux/macOS 沙箱原语放在一起,说明每层解决什么问题、边界在哪里。
VPS 上运行多个 Docker 服务时,只同步容器目录并不等于完成备份。数据库需要一致性的逻辑导出,配置、证书和附件则适合用 rsync 增量同步。
在 EC2 Graviton 实例上跑 Windows 11 ARM 后,最实际的问题就是:x86/x64 的运维工具还能不能用?本文在 t4g.large(Graviton2)上对 Sysinternals Suite 全套工具做了兼容性测试,对比了 ARM64 原生与 x64 模拟的性能差异。
Graviton 实例跑 Windows 11 ARM 用的是 AWS ENA ARM64 驱动,而这个驱动目前只有一个版本(2.2.1)。它能跑满 t4g.large 的网络突发上限吗?本文用 iperf3 做了完整吞吐测试。
Graviton 上 DD 安装的 Windows 11 ARM 用的是微软 inbox StorNVMe.sys,而不是 AWS 官方 AWSNVMe.sys。这个 inbox 驱动会不会成为 IO 瓶颈?本文用 diskspd 做了完整的 IOPS 和吞吐测试,把瓶颈锁定在实例侧。
Graviton 上跑的是非官方方式安装的 Windows 11 ARM,Windows Update 还能正常工作吗?更新会不会把 inbox StorNVMe 驱动替换掉导致系统异常?本文做了完整的补丁扫描、下载、安装验证。