OverlayFS
kernel-featureopen sourceThe union filesystem container engines use by default for images: read-only layers stacked under one writable layer, with copy-on-write.
OverlayFS merges a stack of read-only lower directories with a single writable upper directory into one mounted view. Reads fall through to the topmost layer that has the file; the first write copies the file up into the writable layer (copy-up), and deletions leave whiteout markers. This is the default mechanism behind container images on most Linux setups (engines can swap in other storage drivers, such as btrfs or ZFS, but the layered model is the same): each image layer is a read-only lower directory shared by every container that uses it, and each running container adds only its own thin writable layer, which is why layers are stored once and starting many containers from one image costs almost nothing. The runtime assembles the overlay mount inside the container's mount namespace and pivots the process's root into it. It is plumbing, not a wall: it decides what the filesystem looks like, not what the process may do.
Notable syscalls
are the verbs a program asks the kernel for; each links to its man page.
Strengths
- Image layers are stored once and shared by every container using them
- Containers start instantly, each adds only a thin writable layer
- A standard kernel filesystem, no daemon or special storage required
Limitations
- Not an isolation boundary, only a view of the filesystem
- First write to a large lower file pays a full copy-up
- Whiteout and copy-up semantics have edge cases (renames, hard links)