significant slowdown for first-run of image with --userns=keep-id
and native overlay (not present with fuse-overlayfs?)
#13805
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
I recently noticed that overlayfs landed in the kernel I'm using and that podman supports it directly instead of using the
fuse-overlayfs
driver!I switched some of my container workflows over to this and noticed a significant startup cost on the first execution of an image -- the startup cost doesn't appear to be present in subsequent executions.
Steps to reproduce the issue:
I have narrowed it down to this small shell script -- I'm specifically picking a large image since the image size seems to be a factor here. with a smaller image the difference in startup is noticeable but not as exaggerated.
note: this is a minimal reproduction, my actual use-case involves
--user "$(id -u):$(id -g)"
but that was not needed to reproduce the slowdown.note when using the following storage configuration, this issue is not present:
note this shell script includes
podman system reset -f
which will blow away everything you have, so only run this if you're ok with that!Describe the results you received:
Describe the results you expected:
I expect the execution time of the two
podman run
commands to be similarAdditional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info --debug
:podman info --debug
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/main/troubleshooting.md)
Yes/No -- this is the latest version available to me, and I have checked the guide
Additional environment details (AWS, VirtualBox, physical, etc.):
I have reproduced this on both AWS and on VirtualBox
The text was updated successfully, but these errors were encountered: