taoky

@laminux29 Debian 的话建议从 backports 装 ZFS 。之前遇到过 Debian stable 的 ZFS 会让 kernel oops ，backports 就没问题的情况。

@laminux29 不开玩笑，「跑了半个月就是各种校验和错误」的话，建议跑一下 memtest 。我接触过多个跑了几年的 OpenZFS 阵列从来没遇到过 checksum 报错，如果 checksum 频繁出错的话，几乎可以确定是硬件问题。

@1423

> 镜像站可以公开展示某个 IP 下载了什么包

对，例如 <https://mirrors.tuna.tsinghua.edu.cn/news/release-logs/>，但是公开的日志不包含完整的 IP 地址。

> 使用 http 的镜像站甚至会让运营商知道你下载了什么包

https://web.archive.org/web/20200615045652/https://whydoesaptnotusehttps.com/

> 镜像站更新不及时会阻碍安全更新及时传递

对，所以发行版都不会建议更换安全更新源。例如 Debian 的安装器即使选择了镜像，安全更新也还是从官方拉取（这也是为什么有很多人说装 Debian 的时候换了源下载还慢得要死的原因）

> 镜像站有能力 do evil

有签名机制的 repo 恐怕 do evil 没有那么容易。没有签名的镜像的话……很可惜，只能要么信任镜像站，要么不从镜像站下载。

@0o0O0o0O0o 对于 Debian/Ubuntu 的安全 repo ，在 Release 文件里面可以添加 Valid-Until 字段，比如说 bookworm-security 的 Release:

Date: Wed, 05 Jun 2024 20:30:04 UTC
Valid-Until: Wed, 12 Jun 2024 20:30:04 UTC

如果过期了就会遇到类似 https://unix.stackexchange.com/questions/2544/how-to-work-around-release-file-expired-problem-on-a-local-mirror 的情况。

（另外虽然同学偶尔也会看 V2 ，但是出现故障时通过邮件或者 GitHub issues 反馈得到回复会更快，V2EX 还得等话题浮上来才能更容易被看到

@leiakun btw ，懒得驳斥了，lean 说的话可信度几何，玩软路由的人应该心里清楚。

@ForNickey 在 6/8 3:35 PM 之后应该就恢复了；如果在 5 小时前还有问题那么应该和服务器端没有关联。

@totoroyyw 怀疑遇到了 https://github.com/systemd/systemd/issues/26743 这个 bug 。

@leiakun 单纯的 systemd-networkd 配置问题，故障期间 IPv6 是正常的。

@0x0000009C 很可能是你所在的 IP 段因为滥用行为而被封禁了（至少从 2021 年中旬开始一直到现在，国内的各个镜像站就发现有大量的来自不同 IP 的重复下载大文件的请求，恶意占用了大量带宽，并且没有显著的规律）。需要发信至 lug AT ustc.edu.cn 咨询解除封禁。

registry 是 cache 而不是全量镜像，结果 hit rate 非常低，导致从镜像站下载比直接从官方拉还要慢得多，所以只能（对校外）关掉。以及即使不关掉，Docker Hub 自己也有访问频率限制了（登录状态下每 6 小时只允许 200 次 pull ），即使不关使用体验也不会好到哪里去。

https://mirrors.ustc.edu.cn/help/dockerhub.html#id6 提供了本地搭 registry 缓存的方法，和科大镜像站线上部署的是完全一致的。

@0x0000009C pve (proxmox) 的镜像没有做你所说的限制。