What is Copy-on-Write (COW)?
Learn what copy-on-write is — how fork() shares pages read-only and copies only on a write fault — with an OS interview question answered.
Expected Interview Answer
Copy-on-write is an optimization where two entities share the same underlying physical memory pages read-only until one of them attempts to modify the data, at which point only that modifying party gets a private copy of the affected page.
When fork() creates a child process, instead of duplicating the parent’s entire address space immediately, the kernel marks the parent’s and child’s page table entries as read-only and has both point at the same physical frames. As long as neither process writes, no copying happens at all, which makes fork() extremely fast even for processes with large address spaces. The moment either process attempts a write, the read-only protection triggers a page fault, and the kernel allocates a fresh physical page, copies the original page’s contents into it, remaps the writer’s page table entry to the new private page, and lets the write proceed — the other process is unaffected and still shares the original page. This defers the cost of copying until it is actually necessary, which is a huge win for the very common case of fork() immediately followed by exec(), where the child never touches most of the parent’s memory before replacing its image entirely.
- Makes fork() fast by deferring copying until a write actually occurs
- Wastes no memory or time copying pages that are never modified
- Especially effective for fork()+exec() patterns common in shells
- Generalizes to other sharing scenarios beyond fork, like COW filesystems
AI Mentor Explanation
Copy-on-write is like a coaching manual that a head coach and assistant coach both reference from the same shared binder instead of each printing a personal copy. As long as both only read the drills, one binder serves everyone fine, saving the effort of duplicating it. The moment the assistant wants to scribble a personal annotation on a page, only then does that specific page get photocopied for the assistant, leaving the head coach's original page untouched — copying is deferred until an actual edit happens.
Step-by-Step Explanation
Step 1
Fork with shared pages
fork() marks parent and child page table entries read-only, both pointing at the same physical frames.
Step 2
Read access proceeds normally
Either process reading the shared pages incurs no fault and no copying.
Step 3
Write triggers a fault
A write attempt hits the read-only protection and raises a page fault handled by the kernel.
Step 4
Private copy made
The kernel allocates a new physical page, copies the data, remaps the writer's page table entry, and the write proceeds on the private copy.
What Interviewer Expects
- A clear definition of deferring copy until a write occurs
- How fork() uses COW to be fast without duplicating full address spaces
- What triggers the actual copy — a write-protection page fault
- Awareness of the fork()+exec() case where COW pages are often never even touched
Common Mistakes
- Thinking fork() physically duplicates the entire address space immediately
- Not knowing what triggers the copy (a write-protection page fault, not just any access)
- Forgetting that reads never trigger a copy, only writes do
- Confusing copy-on-write with plain page sharing that has no write protection
Best Answer (HR Friendly)
“Copy-on-write means two processes can share the exact same memory pages as long as they are only reading them, which makes an operation like fork() very cheap since nothing actually gets duplicated up front. It is only the moment one of them tries to change that shared data that the system quietly makes a private copy just for the one making the change, so the other side never even notices.”
Code Example
#include <unistd.h>
#include <stdio.h>
int main(void) {
int shared_value = 42;
pid_t pid = fork(); /* pages marked read-only, shared by both */
if (pid == 0) {
/* child: this write triggers COW fault, allocates a private page */
shared_value = 100;
printf("child sees %d\n", shared_value); /* 100 */
} else {
printf("parent sees %d\n", shared_value); /* still 42 */
}
return 0;
}Follow-up Questions
- Why is fork() followed immediately by exec() a good fit for copy-on-write?
- What page table bit is used to mark a copy-on-write page?
- Does copy-on-write apply to anything besides fork(), such as filesystems?
- What happens to reference counts on a physical page during a COW fault?
MCQ Practice
1. What triggers the actual page copy in copy-on-write?
Reads proceed on the shared page with no copying; only a write hits the write-protection fault that triggers the private copy.
2. Why does fork() benefit heavily from copy-on-write?
Copy-on-write lets fork() share pages instead of duplicating the whole address space, which is especially cheap when followed by exec().
3. After a copy-on-write fault, what happens to the original shared page?
Only the writer gets a new private page; the other process continues using the original shared page unaffected.
Flash Cards
What is copy-on-write? — Sharing pages read-only between entities until a write forces a private copy of just that page.
What triggers the copy in COW? — A write-protection page fault caused by an attempted write to a shared read-only page.
Why is COW important for fork()? — It avoids duplicating the entire address space up front, making fork() fast.
Do reads trigger a COW copy? — No — only writes trigger the copy; reads use the shared page directly.