Hi Andrei,
Like you mentioned, it's application specific. The advantage of
overlayfs here is that you preserve the data that was changed by user
(in case of persistent storage), which of course would hide the data
from rootfs, or your just see the defaults from rootfs if the data was
not changed. With bind mounts you would need to copy default data first
into your tmpfs/ext4 bind mount if you wanna have defaults.
Vyacheslav
I was looking into something like this lately. There are actually two kinds of
write access - volatile (tmpfs) and persistent (to disk). So my approach would
have been to use bind mounts from a tmpfs/ext4 based on configuration per
recipe. Is there any advantage to working with overlayfs in this case? The main
idea is to have state that doesn't come from the ro part of the OS because
otherwise, updates will be shadowed by the overlayfs. So I fail to see the
advantage of using a set of overlayfs mounts instead of bind mounts. At least
with bind mounts, it will always shadow the rootfs bits so you can catch early
this case.
Depending on your use case, most of the times, you'd want this "state" setup
happening pre init (in initramfs, for example), especially if you want to handle
persistent systemd logging or machine id, etc.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152811):
https://lists.openembedded.org/g/openembedded-core/message/152811
Mute This Topic: https://lists.openembedded.org/mt/83284453/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
