Can we default to overlayfs instead of vfs?

[manics]

Comment:

The default storage driver is vfs which is inefficient since it'll create a copy of everything in each layer:

$ podman info -f '{{.Store.GraphDriverName}}'
vfs

overlayfs can be enabled by adding a configuration file:

mkdir -p ~/.config/containers
$ cat << EOF > ~/.config/containers/storage.conf
[storage]
driver = "overlay"
EOF

$ podman info -f '{{.Store.GraphDriverName}}'
overlay

Depending on the age of the kernel this may also require fuse-overlayfs.

fuse-overlayfs is available in conda-forge, though maintenance seems to have stopped over a year ago

[dhirschfeld]

Sounds good to me. How new does your kernel need to be?

[dhirschfeld]

Relatedly, I was wondering if we should set env vars to point to config locations inside the conda env:

• https://github.com/containers/podman/blob/9784d97bd6cef590de781575992f7a685ab1c2c2/docs/source/markdown/podman.1.md#containers_conf
• https://github.com/containers/podman/blob/9784d97bd6cef590de781575992f7a685ab1c2c2/docs/source/markdown/podman.1.md#containers_registries_conf
• https://github.com/containers/podman/blob/9784d97bd6cef590de781575992f7a685ab1c2c2/docs/source/markdown/podman.1.md#containers_storage_conf

[manics]

https://www.redhat.com/sysadmin/podman-rootless-overlay says the kernel needs to be 5.13 for native support, but older kernels should work using fuse-overlayfs. However that requires the system administrator to have installed the base fuse packages, notably this would affect Ubuntu 20.04 which has kernel version 5.4 so maybe best not to do this and instead document it somewhere?

Relatedly, I was wondering if we should set env vars to point to config locations inside the conda env:

Based on the name I think the patch is meant to handle that https://github.com/conda-forge/podman-feedstock/blob/5903263c7fac36dce2230d974bbba70065d59e2f/recipe/0002-Allow-relative-paths-for-system-config-files.patch

but if we can also achieve that by setting environment variable in activate.d (e.g. as in the openjdk feedstock) that sounds easier than maintaining a patch.

[dhirschfeld]

I think env vars would definitely be easier to maintain than a patch so will break that out into a separate issue to tackle whenever anyone has the free time nad inclination to do so.

[manics]

I found this old comment by @jakirkham in 2018:

Taking a step back, historically we have discouraged activation scripts (particularly in c-f) and preferred options like patching hard coded paths for c-b to pick up. So there aren't lots of packages using activation (at least in c-f). So performance may be less of an issue than we think and the tricks mentioned above may already go a long ways.

@jakirkham Is it still the case that conda-forge prefers patches over activate scripts?

[dhirschfeld]

I knew post-link scripts were discouraged but I've always seen activate/deactivate scripts as pretty normal and standard so I'd be interested in the perspective of @conda-forge/core?

[hmaarrfk]

while patches are "harder to main" than activate/deactivate scripts, activate/deactivate scripts become hell with nested environments.

The easiest solution, is to make an argument to upstream as to why including the patch in their source is beneficial. Sometimes they can be quite welcoming! That is the easiest solution to maintain!