Docker Volumes & Storage
Docker Volumes vs Bind Mounts vs tmpfs — When to Use Each
Understanding differences in directory isolation and write performance.
Interview: Interviewers will test your understanding of storage types. Be ready to explain how Volumes bypass the Union File System (OverlayFS) to provide native disk I/O speeds, how permissions differ between Bind Mounts and Volumes, and why tmpfs mounts are ideal for memory-backed security secrets.
Introduction
By default, all files created inside a container are written to a writable container layer. This default storage model has two critical drawbacks: the data is lost when the container is deleted, and writing data involves a filesystem translator (OverlayFS) which incurs a performance penalty.
To solve these problems, Docker offers three mechanisms for mounting files from the host system: Volumes, Bind Mounts, and tmpfs mounts.
Why It Matters
Without persistent storage strategies, databases like PostgreSQL or caches like Redis would lose all data on container restart or upgrade. In addition, high-frequency write operations on OverlayFS will choke system I/O. Choosing the right storage driver directly impacts system performance, security, and scalability.
Real-World Analogy
Think of a container like a hotel room. Writing to the container layer is like writing notes on the room's notepad; when you check out, the maid throws it away. A Bind Mount is like bringing your own personal briefcase into the room—it directly links to your personal belongings back home. A Volume is like renting a secure safety deposit box in the hotel vault—it is managed by the hotel and safe from external tampering. A tmpfs mount is like writing on a dry-erase whiteboard in the room; it is extremely fast to write and read, but disappears the moment the power is shut off.
How It Works
Docker intercepts file operations within containerized directories. When a directory inside the container is designated as a mount point:
- Volumes: Docker creates a directory under its managed path (
/var/lib/docker/volumes/on Linux) and mounts it into the container. - Bind Mounts: Docker mounts the user-specified host path directly into the container's filesystem namespace.
- tmpfs: Docker allocates a segment of host memory and mounts it as a temporary filesystem (
tmpfs) inside the container namespace.
Internal Architecture
The internal storage driver (like overlay2) maps layers together. When a volume or bind mount is declared, Docker bypasses the storage driver's copy-on-write mechanism entirely. Storage calls are translated directly into native Linux kernel system calls (like mount()), achieving host-native speed.
| Feature | Volumes | Bind Mounts | tmpfs Mounts |
|---|---|---|---|
| Host Path | Managed (/var/lib/docker/volumes/) |
Any file/directory path | System Memory (RAM) only |
| Initialization | Copies existing container files into volume | Hides existing container files under mount | Starts empty |
| Portability | High (managed via Docker API/drivers) | Low (depends on host file tree) | High (independent of host disk) |
Visual Explanation
Practical Example
Here is how to run containers using the legacy -v and the modern --mount syntax:
Common Mistakes
1. Missing Host Paths with -v: If you use -v /missing/path:/app/data, Docker will silently create a new directory on your host owned by the root user, which often leads to permission problems. The --mount flag is strict and will fail immediately with an error.
2. Permission Mismatches: Bind mounts map UIDs directly from host to container. If host files are owned by UID 1000, and your container runs as UID 2000, the containerized application will throw a "Permission Denied" error.
Quick Quiz
Q1: Which storage mount type is best suited for sharing code files from host to container during development?
A) Volume
B) Bind Mount
C) tmpfs Mount
Answer: B — Bind mounts map local directories directly, enabling instantaneous file synchronization and hot-reloading.
Q2: What happens when you mount an empty volume to a non-empty container path?
A) The container files are deleted.
B) The files from the container are copied into the volume.
C) The mount fails.
Answer: B — Named volumes automatically pre-populate themselves with the files existing in the container path upon initialization.
Scenario-Based Challenge
Scenario:
You are building a high-speed trading application container. It needs to read static stock tables (50MB) and write transaction logs very quickly. Any transaction logs must persist across host crashes. How should you structure storage?
View SolutionUse a tmpfs mount for the static stock tables to load them directly into memory for ultra-fast, zero-latency reads. For transaction logs, use a Docker Volume to bypass the copy-on-write layer and write directly to host disk, ensuring persistence even if the container or host crashes.
Debugging Exercise
Failure Case:
A container running node backend crashes with Error: Cannot find module 'express'. The developer states express is in the Dockerfile dependencies. They run the container using:
docker run -v $(pwd):/app node-app.
How would you debug this?
View Solution$(pwd):/app), it hides the contents of /app inside the container image, including the compiled node_modules.
Fix: Use an anonymous volume to overlay the node_modules folder, preventing it from being overwritten by the host mount:
Interview Questions
1. What is the difference in file initialization between named volumes and bind mounts?
Named volumes copy files from the container directory into the volume if the volume is empty. Bind mounts are the opposite: the contents of the host directory overwrite or hide whatever is in the container directory.
2. Why do databases run slower on default container filesystems compared to volumes?
Containers use union file systems (like OverlayFS) which use copy-on-write mechanisms, meaning every write requires looking up files through layers, copy-up processes, and writing. Volumes map directly to host filesystem blocks, bypassing the container driver overhead.
Production Considerations
In production environments, mount volumes as read-only (ro) whenever possible to prevent containerized workloads from writing malicious code back onto the host. Clean up orphaned volumes using docker volume prune to prevent disk capacity starvation.