How to use COPY to create seperate layer when invoked

[Detzi88]

Hi,
i got a pretty huge container, and i usually use COPY to split it in manageable layer sizes sub 10 GB or so. Using Buildah i noticed, that using COPY will not necessarily create a new layer, because with my 11 Copy instructions i end up with only 3 Layers. My cmds look like this:
`
COPY --from=reference --exclude=${INSTALL_DIR}/A --exclude=${INSTALL_DIR}/B ${INSTALL_DIR} ${INSTALL_DIR}

COPY --from=reference ${INSTALL_DIR}/A ${INSTALL_DIR}/A

COPY --from=reference ${INSTALL_DIR}/B ${INSTALL_DIR}/B
[...]
`
is there a way to make this work with buildah?

EDIT:
"--layers=true" is not supported:
Error: building at STEP "COPY --layers=true --from=reference --exclude=${INSTALL_DIR}/A --exclude=${INSTALL_DIR}/B ${INSTALL_DIR} ${INSTALL_DIR}": COPY only supports the --chmod=<permissions>, --chown=<uid:gid>, --from=<image|stage>, --link, --parents, and --exclude=<pattern> flags

--link isn't either despite it telling me otherwise above:
Error: building at STEP "COPY --link --from=reference --exclude=${INSTALL_DIR}/A --exclude=${INSTALL_DIR}/B ${INSTALL_DIR} ${INSTALL_DIR}": COPY --link is not supported

[nalind]

The --layers=true flag would be supplied to buildah build at the command line, not as an argument to the COPY instruction in a Dockerfile, and when used it will have buildah build commit a new intermediate image for each instruction it processes.
The --link flag for COPY and ADD instructions should be recognized in 1.41.0 and later, which is in podman 5.6 rc1 and later, but if I'm remembering it right, it will be ignored if the default of --layers=false is in effect.

[Detzi88]

Thank you for your reply! Your absolutely right. I just put the --layers=true option in the wrong script. Now that it is enabled, my runner is eating disk space, like a LOT. My resulting container with witch i currently test had around 40GB ish before enabling the --layers=true option. Now that this is set, i uses up 1.5T of disk space and then crahes with a "out of disk space" error (i haven't found out how much it needs exactly and how large the resulting image would be).

Is that expected behavior or even intended? For me that makes no sense at all.

[nalind]

The root mountpoint being on an overlay filesystem means regular overlay isn't available because the kernel's overlay filesystem can't be run on top of an overlay filesystem -- that's assuming the GraphRoot location that buildah info lists is on that filesystem. If buildah info includes GraphDriverName": "vfs" in its output, then every new step in the build is starting with an entire copy of the previous step, and that can accrue quickly.

Running with storage on top of an xfs filesystem, which provides "reflinks", can help here, as the "vfs" logic can use that filesystem feature to reduce the amount of space it uses.

Attempting to use fuse-overlayfs is another option: set driver = "overlay" in the [storage] section and mount_program = "/usr/bin/fuse-overlayfs" in the [storage.options.overlay] section of storage.conf, which can usually be found either in /etc/containers or /usr/share/containers, and then see if buildah info confirms that it was able to start with that configuration, and then see if buildah build is able to successfully run builds that use RUN instructions.

[Detzi88]

switching from vfs to overlay did the trick. Thank you!