-
Notifications
You must be signed in to change notification settings - Fork 85
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
overlay driver is very slow in podman-in-podman builds with large COPY layer #401
Comments
I am not sure how advisable is it to use overlay inside overlay, usually its not and people see all sorts of issues running in this configuration but it seems you have already investigated this and issue looks with the |
I'll take a look, but I'd say that is somehow expected with fuse-overlayfs. FUSE significantly slows down I/O operations and your image is made of many small files (it takes more than a minute on XFS+LVM+LUKS). VFS instead, once the layer is extracted, is much faster than FUSE and even more than native overlay. overlay on top of overlay doesn't work, but if you use a volume for Have you already tried that? |
@giuseppe Yes I did try that, but it didn't change anything. Transfer rate remained unchanged in the child container. But this is very easy if you want to try it yourself just use the reproducer I linked in the issue. |
cache the number of links for a directory instead of calculating it on every stat. It makes a huge difference when the directory has a lot of entries. Closes: containers#401 Signed-off-by: Giuseppe Scrivano <[email protected]>
opened a PR to address the performance issue in fuse-overlayfs: #402 |
v1.13 is out |
@giuseppe Thank you so much! I can't wait to test it out! |
Issue Description
Hello!
TLDR;
overlay
driver with a COPY layer that is trying to copy a large number of files & bytes in a nested container build podman-in-podman is so slow as to be unusable.When using
overlay
storage driver to do a nested podman build inside a running container, it takes over an hour to run a COPY layer that is coping over 130k files and 1.3gb. Whereas when running the exact same build with thevfs
driver it completes in 1.5 minutes.Doing some analysis it appears that
fuse-overlayfs
transfers a large chunk of data right at the beginning then slows way down until it is only transferring a trickle of bytes/s. It can take a very long time to complete (> 1 hour) and then sometimes the build errors out when trying to write the last layer.In contrast
vfs
driver transfers the bytes at a consistent rate from start to finish so the build completes in a reasonable amount of time, just around 2 minutes.I have a reproducer image for
overlay
as well the exact same image only with the storage driver set tovfs
that works for contrast. See the reproduction steps below.Steps to reproduce the issue
To help make reproducing this issue easy, I have uploaded two images that contain a script called
nested_build.sh
that run the nested build and demonstrates the issue. The base images are based onFROM quay.io/fedora/fedora:38
and contain asrc/html/
directory contains a statically generated website that has > 130k files and around 1.3gb in size. The nested image build is based onregistry.redhat.io/ubi9/httpd-24
and the all it does isCOPY html /var/www/html
You can see all the base image Container files in the repo here: https://github.com/Jared-Sprague/overlay_bug
Steps to reproduce the issue
vfs
it should take about 2 min to complete:It ran successfully if you see the
localhost/website
image output:overlay
:Describe the results you received
The results are that the
vfs
driver completes in ~2min where as theoverlay
driver takes > 1 hour or doesn't complete at all.Describe the results you expected
overlay
driver should be at least as fast asvfs
driver in nested builds.podman info output
Parent container podman info
The text was updated successfully, but these errors were encountered: