You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the default provided config of docker it seems to default to overlay2 storage driver which, according to the docs, is the recommended option for most environments but in reality dockerd on OpenWRT changes to VFS.
When launching dockerd through init.d the following error messages can be seen:
...
Mon Nov 18 08:44:43 2024 kern.err kernel: [ 767.873468] overlayfs: filesystem on '/opt/docker/check-overlayfs-support1084625961/upper' not supported as upperdir
...
Mon Nov 18 08:44:44 2024 daemon.err dockerd[8718]: time="2024-11-18T08:44:44.134747341Z" level=warning msg="WARNING: No swap limit support"
It seems that dockerd does not support overlay FS on top of an already existing overlay FS which is the usual case for OpenWRT environment according to the wiki. I have found someone already mentioning this on stack overflow here but according to kernel docs "The lower filesystem can even be another overlayfs". I would suppose dockerd still does not support such feature anyway.
root@OpenWrt:~# df -h /opt/docker/
Filesystem Size Used Available Use% Mounted on
overlayfs:/overlay 955.4M 174.1M 781.2M 18% /
Dockerd defaults to VSF storage driver which is less efficient and not recommended according to docker docs: "Each layer is a directory on disk, and there is no copy-on-write support. To create a new layer, a "deep copy" is done of the previous layer. This leads to lower performance and more space used on disk than other storage drivers..."
There is also a no swap limit warning but I haven't looked into the reason and causes behind it.
I mention the workaround I used here #11839 (comment).
If I recall correctly, it was discussed somewhere here and the consensus was that users will be configuring their disk's for docker such as using an additional FS on an additional disk.
That said, your aren't the first, so I wonder if there is a better solution.
Also, I don't recall the specifics of the workaround, but from what I recall the /overlay/ dir is something like where the overlay FS is built upon. Seemed to work for me when I used it but maybe there is technically a possible issue.
Maintainer: @G-M0N3Y-2503
Environment: x86/64 (VM), OpenWrt SNAPSHOT r25603-1a47ce5ff2
Description:
With the default provided config of docker it seems to default to overlay2 storage driver which, according to the docs, is the recommended option for most environments but in reality dockerd on OpenWRT changes to VFS.
packages/utils/dockerd/files/dockerd.init
Line 172 in 9fc92ea
When launching dockerd through init.d the following error messages can be seen:
It seems that dockerd does not support overlay FS on top of an already existing overlay FS which is the usual case for OpenWRT environment according to the wiki. I have found someone already mentioning this on stack overflow here but according to kernel docs "The lower filesystem can even be another overlayfs". I would suppose dockerd still does not support such feature anyway.
Dockerd defaults to VSF storage driver which is less efficient and not recommended according to docker docs: "Each layer is a directory on disk, and there is no copy-on-write support. To create a new layer, a "deep copy" is done of the previous layer. This leads to lower performance and more space used on disk than other storage drivers..."
There is also a no swap limit warning but I haven't looked into the reason and causes behind it.
Main question
What would be some of possible solutions to make it so dockerd uses overlayFS as it's storage driver instead of VFS?
Overlayfs testing
I tried to work around this situation by creating a new directory directly under
/overlay/
(which I've heard is never recommended!)I have managed to at least run
docker run hello-world
which seems to be working fine as well as docker info shows that the storage driver is overlayAlso here is dockerd output:
I am not sure if this "work around" is viable though, mainly because
/overlay/
directory is usedThe text was updated successfully, but these errors were encountered: