On Wed, Mar 20, 2024 at 07:55:31PM -0400, Steve Petrie via talk wrote:
Greetings To The GTALUG Community:
I'm trying to discover where an overlay filesystem is mapped, for a Debian live boot from a USB stick.
After perusing a dog's breakfast of output from various linux commands, I am appealing to GTALUG members for guidance.
* * * * * *
I boot live Debian 11 linux from a USB memory stick.
This provides an overlay filesystem: ... user@debian:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 7.8G 0 7.8G 0% /dev tmpfs 1.6G 1.6M 1.6G 1% /run /dev/sdb1 3.5G 3.5G 0 100% /run/live/medium /dev/loop0 2.9G 2.9G 0 100% /run/live/rootfs/filesystem.squashfs tmpfs 7.8G 1.6G 6.3G 20% /run/live/overlay overlay 7.8G 1.6G 6.3G 20% / tmpfs 7.8G 0 7.8G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 7.8G 8.0K 7.8G 1% /tmp tmpfs 1.6G 1.7M 1.6G 1% /run/user/1000 /dev/sdc1 59G 1.7G 57G 3% /media/user/245B-74A8 /dev/sda2 1.8T 767G 958G 45% /media/user/32ec11e8-082c-4ca5-b751-dc2852f9d5e2 user@debian:~$
So it appears that it uses a squashfs file (compressed readonly filesystem) as root with a tmpfs (ramdisk) overlay. That way you can write to it, and the writes will go to the ramdisk, while any unchanged file comes from the compressed squashfs. overlayfs allows you to put one filesystem on top of another and the second one handles writes and any files it has replace (by hiding the original) existing files in the base filesystem. So with this setup, the system appears to have a writeable root filesystem but is completely non persistent. Another common use of overlay is docker containers. Docker images are built by taking an existing image as a starting point (well you can also start from SCRATCH which is empty) and then make changes on top of that. When you run a docker container, it mounts the base layer, then overlays the next layer, then the next layer, etc for any number of changes made to the docker image as it was built and finally a writeable layer on top to store any changes made by the container relative to the docker image it was started from. So it provides a convinient copy on write mechanism which saves space by allowing multiple images to share a base image and multiple containers to share an image on disk and only have to store the deltas they have made to it. -- Len Sorensen