Explain layered filesystems like OverlayFS and their efficiency vs monolithic models

WHAT THIS TESTS: The interviewer wants to know if you understand the mechanics of container storage beyond docker run. Specifically they are probing for knowledge of union filesystems, the copy-on-write principle, content-addressable storage, and the operational impact on CI/CD and registry bandwidth. Senior candidates should connect the filesystem abstraction to image immutability, layer caching, and security boundaries between containers sharing the same base.

A GOOD ANSWER COVERS: First, define the three mount points in OverlayFS: lowerdir representing read-only image layers ordered from base to top, upperdir representing the writable container layer, and merged presenting a unified filesystem view to the process. Second, explain copy-on-write: when a container modifies a file from a lower layer, the file is copied up to the upperdir before the write occurs, leaving the original layer untouched and preserving immutability. Third, describe storage efficiency: because layers are content-addressable and shared, ten containers based on the same Ubuntu image reuse the exact same on-disk blocks rather than storing ten copies. Fourth, contrast distribution efficiency: a monolithic approach ships an entire disk image on every version bump, while a layered model pushes and pulls only the changed layers; a 50MB application update atop a 1GB base image therefore transfers just 50MB plus metadata. Fifth, mention practical limits: layer depth impacts performance, and excessive copy-up operations on large files can create latency, which is why build optimization matters.

COMMON WRONG ANSWERS: A red flag is describing layers as simple zip files or compression tricks rather than filesystem diffs. Another is claiming OverlayFS is the image format; clarify that OCI specifies the layer tarballs and manifest, while OverlayFS is merely a Linux kernel driver that assembles them at runtime. Avoid saying copy-on-write means no disk space is used; the upperdir consumes space for every modified block. Also do not assert that layers are always merged in userland; OverlayFS is an in-kernel filesystem since Linux 3.18.

LIKELY FOLLOW-UPS: The interviewer may ask how to reduce layer bloat in Dockerfiles, how AUFS differs from OverlayFS, or what happens when you delete a file from a lower layer (whiteouts). They might also probe the security implications of sharing base layer inodes across untrusted containers, or ask why podman rootless containers use fuse-overlayfs instead of kernel OverlayFS.

ONE CONCRETE EXAMPLE: Imagine a Node.js application built FROM node:18. The base image is 900MB. You add 20MB of source code in a new layer. With a monolithic model, every git push that changes one line of code forces users to download a 920MB image. With OverlayFS layers, the registry already has the node:18 layer cached on the host; only the 20MB diff layer is pushed and pulled. If ten microservices share that same node:18 base, the host stores it once, not ten times, saving roughly 8GB of disk.