an overlay filesystem

An overlay filesystem is the layering trick that lets containers share a common base image cheaply while each still gets its own writable space. Imagine a printed reference book that you must not write on, covered by a sheet of clear acetate: you read straight through the acetate to the page beneath, but any notes you make go onto the acetate, leaving the book pristine. Many people can share one copy of the book, each with their own acetate sheet of changes. That stacking of a read-only base under a writable top is exactly what an overlay (or union) filesystem does.

Concretely it merges two or more layers into one view. There is a lower layer that is read-only and shared (the container image: the operating-system files, libraries, and the app), and an upper layer that is writable and private to one container. When the container reads a file, the filesystem looks in the upper layer first and falls back to the lower; what it sees is the merged result, as if it were one normal filesystem. When the container writes to a file that exists only in the read-only lower layer, the filesystem makes a private copy into the upper layer first and edits that — a copy-on-write step — so the shared base is never touched and other containers using the same base are unaffected.

Overlay filesystems matter because they are what makes container images so space-efficient and fast to start: a hundred containers from the same image share one read-only copy of its gigabytes, and each adds only a thin upper layer holding the few files it actually changes. This is also why a container's writes vanish when it is deleted unless you deliberately store them elsewhere — the writable upper layer is ephemeral by design. The honest caveat: overlay writes that must first copy a large file up can be slower than writing on a plain filesystem, and the layering only saves space when containers genuinely share the same lower layers.