从 Jfrog artifactory 中删除工件不会释放磁盘 space
Deleting artifacts from Jfrog artifactory doesn't result in freed disk space
我有 Artifactory Jfrog 6.16.0 Pro。我针对存储库安装了插件 artifactCleanup 和 运行。它删除了大约 500GB。
下一步，我从垃圾桶中删除文件，现在它为零。
最后一个我运行手动“垃圾收集”
Space 没有被释放。在存储部分，它显示了以下信息：
Binaries Size: 1.67 TB
Artifacts Size: 663.15 GB
Optimization: 257.79%
请指教，在删除工件后可以做什么来释放space？
谢谢！
首先让我们了解一下 Artifactory GC 是如何工作的。来自 docs:
When a new file is deployed, Artifactory checks if a binary with the
same checksum already exists and if so, links the repository path to
this binary. Upon deletion of a repository path, Artifactory does not
delete the binary since it may be used by other paths. However, once
all paths pointing to a binary are deleted, the file is actually no
longer being used. To make sure your system does not become clogged
with unused binaries, Artifactory periodically runs a "Garbage
Collection" to identify unused ("deleted") binaries and dispose of
them from the datastore. By default, this is set to run every 4 hours
and is controlled by a cron expression.
这意味着如果我将同一个 5GB 文件存储 100 次，那么我们的工件大小为 500GB，而我们的二进制文件大小仍然为 5GB。这是因为 Artifactory 通过基于校验和的存储进行重复数据删除。
二进制文件的大小永远不应超过工件的大小，恰恰相反，优化不应通过 100%。但是，这基本上是根据您 运行 宁“df”命令得到的计算得出的，因此如果 GC 没有 运行 它会显示那些二进制文件仍然存在。
这将我们带到了您的问题，这可能不是问题，而是在先前链接的文档中也指出的预期行为：
Unreferenced binaries, (including existing unreferenced binaries or
artifacts that were manually deleted from the trashcan), will be
deleted during the previous Full GC strategy that runs every 20 GC
iterations (configurable,
'artifactory.gc.skipFullGcBetweenMinorIterations=20').
这告诉我们二进制文件的实际删除只会每 20 次迭代发生一次。
请尝试手动触发GC 20次；完整 GC 的输出将与常规 GC 不同，为您提供已删除内容的摘要。
如果这不起作用，请查看 Artifactory 用户的权限以确保它可以删除文件。
我有 Artifactory Jfrog 6.16.0 Pro。我针对存储库安装了插件 artifactCleanup 和 运行。它删除了大约 500GB。 下一步，我从垃圾桶中删除文件，现在它为零。 最后一个我运行手动“垃圾收集”
Space 没有被释放。在存储部分，它显示了以下信息：
Binaries Size: 1.67 TB
Artifacts Size: 663.15 GB
Optimization: 257.79%
请指教，在删除工件后可以做什么来释放space？
谢谢！
首先让我们了解一下 Artifactory GC 是如何工作的。来自 docs:
When a new file is deployed, Artifactory checks if a binary with the same checksum already exists and if so, links the repository path to this binary. Upon deletion of a repository path, Artifactory does not delete the binary since it may be used by other paths. However, once all paths pointing to a binary are deleted, the file is actually no longer being used. To make sure your system does not become clogged with unused binaries, Artifactory periodically runs a "Garbage Collection" to identify unused ("deleted") binaries and dispose of them from the datastore. By default, this is set to run every 4 hours and is controlled by a cron expression.
这意味着如果我将同一个 5GB 文件存储 100 次，那么我们的工件大小为 500GB，而我们的二进制文件大小仍然为 5GB。这是因为 Artifactory 通过基于校验和的存储进行重复数据删除。
二进制文件的大小永远不应超过工件的大小，恰恰相反，优化不应通过 100%。但是，这基本上是根据您 运行 宁“df”命令得到的计算得出的，因此如果 GC 没有 运行 它会显示那些二进制文件仍然存在。
这将我们带到了您的问题，这可能不是问题，而是在先前链接的文档中也指出的预期行为：
Unreferenced binaries, (including existing unreferenced binaries or artifacts that were manually deleted from the trashcan), will be deleted during the previous Full GC strategy that runs every 20 GC iterations (configurable, 'artifactory.gc.skipFullGcBetweenMinorIterations=20').
这告诉我们二进制文件的实际删除只会每 20 次迭代发生一次。 请尝试手动触发GC 20次；完整 GC 的输出将与常规 GC 不同，为您提供已删除内容的摘要。
如果这不起作用，请查看 Artifactory 用户的权限以确保它可以删除文件。