对象存储分段残留导致空间占用问题

概述

在使用对象存储时，为了方便大文件上传和提高上传效率、并发等等，经常会使用s3 multipart upload，也就是分段上传。我们知道分段上传一般分三个不分，init、upload part和complete。
根据gc池原理，当在upload part调用abort multipart接口，取消分段上传，已经上传的分段会进入gc，慢慢回收释放空间。
由于index-pool的异步结构，以及在分段上传过程中发生异常中断，都可能会导致分段对象残留在rados pool层中，从而占用很大空间。
根据实际生产场景，某些实际object对象只有500G的桶存储池额外占用可能达到5T甚至更多。
如果这种分段仍被底层记录，可以查到分段id，是可以取消上传，让这些分片进入gc。如果这些分段已经不在底层记录中，这些_multipart对象是没法通过分段abort清理的，需要额外底层手段（此处先不赘述）。

abort multipart

在理解了分段上传逻辑和碎片产生逻辑后，不难理解，对底层来说，即发送一个请求，告知对应的分段上传已被取消，这样底层会让这些part从data pool正常进入gc pool。
无论使用s3cmd亦或是sdk中的abortmultipart接口都可以清理，这里以s3cmd为例。
具体操作如下：

列出桶当前所有的分段上传

s3cmd mlutipart s3://bucket-name

会返回3列分别问init时间，path和id，其中path和id下一步需要用到

查询某个分段具体的未完成的分段id

s3cmd listmp  id s3://bucket-name/key-字符后缀（对应上一条命令返回的id和path）

可以看到这个分段具体还有哪些part残留，每个part都有一个part-id

取消分段

s3cmd abortmp part-id

底层查询对象数和存储池占用，确认完成清理