Mirrors 磁盘占用问题及对策

[cuihaoleo]

过去几个月，Mirrors 的 ZFS pool 一直处于存储空间不足的状态。11月25日，我们删除了 mageia 镜像，释放了 1T 左右的空间。 前两日 Mirrors 存储空间再度耗尽，我们删除了 PyPI 源，又释放了近4T空间。

当前 Mirrors ZFS Pool 空间紧张问题（以及由此引发的性能问题）得到一定缓解。但是，空间问题限制了 Mirrors 的发展，堆积的 mirrorrequest 难以付诸实施。即便不扩展新镜像，现有镜像占用空间也在不断扩大，迟早会再度空间不足。有必要尽早应对磁盘空间不足问题，而不是等到出现问题时再被动地删镜像。

目前讨论过的一些方案有：

• 硬盘扩容：最直接的方案。但目前 Mirrors 所有硬盘位都已经插满，我们的 raidz3 pool 只能逐盘替换重建，尚不清楚需要多长时间完成以及会带来多大的性能损耗。
• 淘汰镜像：一些用户非常少的镜像，尤其是占用空间多且用户少的，可以考虑删除或改为反向代理。目前需要设计一个活跃度评估方案。

希望各位提供一些意见。可以具体实施的项目，可以另外开 issue 讨论方案和追踪进度。

[wi24rd]

淘汰一些用户量少的镜像前最好double check一下是否该镜像在大陆是唯一的镜像，对于这种情况我觉得还是不要删掉。

…

On Thu, Jan 24, 2019 at 7:17 PM CUI Hao ***@***.***> wrote: 过去几个月，Mirrors 的 ZFS pool 一直处于存储空间不足的状态。11月25日，我们删除了 mageia 镜像，释放了 1T 左右的空间。 前两日 Mirrors 存储空间再度耗尽，我们删除了 PyPI 源，又释放了近4T空间。 当前 Mirrors ZFS Pool 空间紧张问题（以及由此引发的性能问题）得到一定缓解。但是，空间问题限制了 Mirrors 的发展，堆积的 mirrorrequest 难以付诸实施。即便不扩展新镜像，现有镜像占用空间也在不断扩大，迟早会再度空间不足。有必要尽早应对磁盘空间不足问题，而不是等到出现问题时再被动地删镜像。 目前讨论过的一些方案有： - *硬盘扩容*：最直接的方案。但目前 Mirrors 所有硬盘位都已经插满，我们的 raidz3 pool 只能逐盘替换重建，尚不清楚需要多长时间完成以及会带来多大的性能损耗。 - *淘汰镜像*：一些用户非常少的镜像，尤其是占用空间多且用户少的，可以考虑删除或改为反向代理。目前需要设计一个活跃度评估方案。 希望各位提供一些意见。可以具体实施的项目，可以另外开 issue 讨论方案和追踪进度。 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#263>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANYQzP0aw8o0uHkmTPhy-3tpVXkMc2VVks5vGZZfgaJpZM4aQp8c> .

-- GNU powered it... GPL protect it... GOD blessing it... Regards, Wi24rd

[cuihaoleo]

有道理。不过目前的状况是 TUNA 和 USTC 的镜像有很多重叠，很多用户量不大的镜像，我觉得两边都搞是没啥必要的。不如先发制人，速速甩锅给 TUNA（雾

淘汰一些用户量少的镜像前最好double check一下是否该镜像在大陆是唯一的镜像，对于这种情况我觉得还是不要删掉。

[anjia0532]

可以将重叠的，反代到tuna上。

[taoky]

前几天我和 @iBug 商量，打算把 mirrors2 上面 (占用空间 >= 0.5 TB) 且 (访问量很小 或 更新幅度很低) 的镜像迁移到 mirrors3 上面，用 NFS 的办法缓解容量问题。

按照 ZFS 的 80% rule 的话，pool0 至少要空出 8.3 TB 的剩余空间才能够保证足够好的性能。