discussions Mirrors 磁盘占用问题及对策

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

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

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

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

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

Jan 24 '19 11:01 cuihaoleo

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

On Thu, Jan 24, 2019 at 7:17 PM CUI Hao [email protected] 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 https://github.com/ustclug/discussions/issues/263, or mute the thread https://github.com/notifications/unsubscribe-auth/ANYQzP0aw8o0uHkmTPhy-3tpVXkMc2VVks5vGZZfgaJpZM4aQp8c .