-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
podman system prune: Inconsistent "Total reclaimed space" #10215
Labels
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
Comments
openshift-ci-robot
added
the
kind/bug
Categorizes issue or PR as related to a bug.
label
May 5, 2021
Thanks for reaching out! I have high hopes that this should be fixed with #10147. |
@2xB I should have done this way earlier but I used your test script and tested with the changes @vrothberg made and I got results that seem to be correct. So I'm guessing / hoping the issue is resolved :)
|
Thanks for checking! Apologies for not getting back to the issue after #10147 was merged. |
github-actions
bot
added
the
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
label
Sep 21, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
podman system prune --all
produces a message ofTotal reclaimed space: 273.2GB
, while my file system only shows 45.0 GB less (and it never used that much for container storage). There exists a reproducible script to test this.This was discussed in #8831 .
(I am not 100% certain that the bug was first seen with the
--all
keyword, but the demonstration below shows this effect with--all
, making it very likely that this was also how I initially saw that error.)Steps to reproduce the issue:
This is reproducibly packed into a single bash script, using a podman-in-podman setup to make this reproducible and relatively clean without interfering with any pre-existing containers when executing
podman system prune
. Just for the record, I'm using rootless Podman 3.1.0 on Manjaro Linux and inside the Fedora container is a Podman 3.1.2 during my tests. But theoretically this script should work on any system without interference with existing podman containers.The script sets up a podman image
issue8831_2
with some podman image files inside that are deleted usingpodman system prune -f
andpodman system prune -f --all
, first in that order (marks 1 and 2) and then - rolling back toissue8831_2
- in the other order (marks 3 and 4).The script (click to expand)
Describe the results you received:
The result - cleaned a bit:
It is clear:
686.5MB + 2.619GB != 3.992GB (+ 0B )
Describe the results you expected:
Something consistent.
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info --debug
:Output (click to expand)
``` Inside the container: arch: amd64 buildahVersion: 1.20.1 cgroupManager: systemd cgroupVersion: v1 conmon: package: conmon-2.0.27-2.fc34.x86_64 path: /usr/bin/conmon version: 'conmon version 2.0.27, commit: ' cpus: 8 distribution: distribution: fedora version: "34" eventLogger: journald hostname: 13d4fc8a28bc idMappings: gidmap: null uidmap: null kernel: 5.9.16-1-MANJARO linkmode: dynamic memFree: 207339520 memTotal: 8088653824 ociRuntime: name: crun package: crun-0.19.1-2.fc34.x86_64 path: /usr/bin/crun version: |- crun version 0.19.1 commit: 1535fedf0b83fb898d449f9680000f729ba719f5 spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL os: linux remoteSocket: path: /run/podman/podman.sock security: apparmorEnabled: false capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT rootless: false seccompEnabled: true selinuxEnabled: false slirp4netns: executable: "" package: "" version: "" swapFree: 13671735296 swapTotal: 17179865088 uptime: 37h 54m 35.03s (Approximately 1.54 days) registries: search: - registry.fedoraproject.org - registry.access.redhat.com - docker.io - quay.io store: configFile: /etc/containers/storage.conf containerStore: number: 0 paused: 0 running: 0 stopped: 0 graphDriverName: vfs graphOptions: {} graphRoot: /var/lib/containers/storage graphStatus: {} imageStore: number: 0 runRoot: /run/containers/storage volumePath: /var/lib/containers/storage/volumes version: APIVersion: 3.1.2 Built: 1619097088 BuiltTime: Thu Apr 22 13:11:28 2021 GitCommit: "" GoVersion: go1.16 OsArch: linux/amd64 Version: 3.1.2 ```Package info (e.g. output of
rpm -q podman
orapt list podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
Container, see script above.
The text was updated successfully, but these errors were encountered: