The journey of a write() call — click each layer to explore.
Your Program
— system call boundary —
Data Flow
wow
OS Page Cache
Drive Buffer
data lost here on power cut. Click to see what a power cut does here.
Physical Disk
What happens when the power goes out here?
If power fails while your data is sitting in any of the top four layers — your program's memory, the system call in progress, the OS page cache, or the drive's buffer — that data is gone. It never reached physical storage.This is not a bug in buffering. It is a deliberate trade-off: you accept a small risk of data loss in exchange for a large gain in speed.Most software makes this trade happily — the risk of a crash is small and the performance gain is large. But some software cannot afford to make it. Banking systems, medical records, and crash logs use unbuffered writes and explicit flush calls so that data is permanent the instant it is written, regardless of what happens to the machine a millisecond later.Auto-save exists precisely because of this. Your editor flushes every few minutes so a crash loses minutes of work — not hours.
OS page cache — the most important buffer
Your data lands here first — not on disk. The OS accepts it into the page cache (a region of RAM), tells your program "Done!", and then writes to disk in the background at its own pace.This is why saving a large file feels almost instant. The application saw the OS say "I have it" — but the data has not touched the physical drive yet.Read the same file twice in quick succession and the second read is nearly instant too — because the data is already sitting here from the first time.⚠ Power cut here = data gone. It was in RAM, not on disk.More RAM on your machine means a larger page cache, which means more files stay buffered in memory. This is a real, measurable reason why adding RAM makes file-heavy work feel faster.
Your program — user space
Your program calls write() — but it has no direct access to the disk. It runs in user space, a restricted zone where hardware is completely off-limits to regular programs.Think of it like a restaurant. You (the program) can place an order, but you cannot walk into the kitchen. The OS kernel is the kitchen — it does the actual work and hands the result back to you.The moment write() is called, your program hands the data to the OS and waits. The CPU switches from user mode to kernel mode to handle the request, then switches back when done.This is why crashes lose unsaved work — your edits lived only in this layer, in your program's memory. The OS never saw them.
The drive's internal buffer — one more waiting room
Most people are surprised by this one: the storage device itself has its own small internal buffer. Even after the OS hands data to the drive, it may sit here briefly before being physically written to the magnetic platter or flash cells.⚠ Still not permanent. A power cut here loses the data too.This is the layer most people forget about when they think "OS flushed the buffer, so it must be safe." It is not necessarily safe yet.To guarantee data has genuinely reached the physical storage medium, an application can call fsync() — a system call that forces the drive to flush its own buffer all the way to the hardware. Most applications never need this, but databases call fsync() constantly. When your bank confirms a transaction, fsync() is part of why that confirmation means something.
The system call boundary — crossing costs time
This line is not just a diagram label — it represents a real hardware event. When your program makes a system call, the CPU physically switches from user mode to kernel mode to handle it, then switches back when finished.That switch is not free. It takes time. This is why programs try to make as few system calls as possible — instead of calling write() one byte at a time, they batch data and cross this line as rarely as possible.Your programming language handles this batching automatically through buffered I/O. You almost never think about it, but it is happening constantly behind the scenes.Above this line: your code controls what happens. Below it: the OS kernel has full authority and full hardware access.
Physical storage — the only layer that survives a power cut
Data is finally permanent here — written to the magnetic platter or flash cells. If the power goes out now, the data survives.But reaching this layer is slow — and that slowness is the entire reason all the buffering above exists. RAM operates in nanoseconds. A spinning hard drive needs milliseconds to physically move a read arm to the right track. That is a million-to-one speed difference.SSDs have no moving parts, but they are still far slower than RAM because of how flash memory cells are organized and erased. The physics are simply different at each layer.Buffering lets your program work at RAM speed almost all the time, only touching this slow layer in large, efficient batches — instead of one tiny write at a time..
The system call boundary — crossing costs time
This line is not just a diagram label — it represents a real hardware event. When your program makes a system call, the CPU physically switches from user mode to kernel mode to handle it, then switches back when finished.That switch is not free. It takes time. This is why programs try to make as few system calls as possible — instead of calling write() one byte at a time, they batch data and cross this line as rarely as possible.Your programming language handles this batching automatically through buffered I/O. You almost never think about it, but it is happening constantly behind the scenes.Above this line: your code controls what happens. Below it: the OS kernel has full authority and full hardware access.
Lorem ipsum dolor sit
The journey of a write() call — click each layer to explore.
James
Created on April 7, 2026
Start designing with a free template
Discover more than 1500 professional designs like these:
View
Pastel Color Presentation
View
Visual Presentation
View
Relaxing Presentation
View
Modern Presentation
View
Colorful Presentation
View
Modular Structure Presentation
View
Chromatic Presentation
Explore all templates
Transcript
The journey of a write() call — click each layer to explore.
Your Program
— system call boundary —
Data Flow
wow
OS Page Cache
Drive Buffer
data lost here on power cut. Click to see what a power cut does here.
Physical Disk
What happens when the power goes out here?
If power fails while your data is sitting in any of the top four layers — your program's memory, the system call in progress, the OS page cache, or the drive's buffer — that data is gone. It never reached physical storage.This is not a bug in buffering. It is a deliberate trade-off: you accept a small risk of data loss in exchange for a large gain in speed.Most software makes this trade happily — the risk of a crash is small and the performance gain is large. But some software cannot afford to make it. Banking systems, medical records, and crash logs use unbuffered writes and explicit flush calls so that data is permanent the instant it is written, regardless of what happens to the machine a millisecond later.Auto-save exists precisely because of this. Your editor flushes every few minutes so a crash loses minutes of work — not hours.
OS page cache — the most important buffer
Your data lands here first — not on disk. The OS accepts it into the page cache (a region of RAM), tells your program "Done!", and then writes to disk in the background at its own pace.This is why saving a large file feels almost instant. The application saw the OS say "I have it" — but the data has not touched the physical drive yet.Read the same file twice in quick succession and the second read is nearly instant too — because the data is already sitting here from the first time.⚠ Power cut here = data gone. It was in RAM, not on disk.More RAM on your machine means a larger page cache, which means more files stay buffered in memory. This is a real, measurable reason why adding RAM makes file-heavy work feel faster.
Your program — user space
Your program calls write() — but it has no direct access to the disk. It runs in user space, a restricted zone where hardware is completely off-limits to regular programs.Think of it like a restaurant. You (the program) can place an order, but you cannot walk into the kitchen. The OS kernel is the kitchen — it does the actual work and hands the result back to you.The moment write() is called, your program hands the data to the OS and waits. The CPU switches from user mode to kernel mode to handle the request, then switches back when done.This is why crashes lose unsaved work — your edits lived only in this layer, in your program's memory. The OS never saw them.
The drive's internal buffer — one more waiting room
Most people are surprised by this one: the storage device itself has its own small internal buffer. Even after the OS hands data to the drive, it may sit here briefly before being physically written to the magnetic platter or flash cells.⚠ Still not permanent. A power cut here loses the data too.This is the layer most people forget about when they think "OS flushed the buffer, so it must be safe." It is not necessarily safe yet.To guarantee data has genuinely reached the physical storage medium, an application can call fsync() — a system call that forces the drive to flush its own buffer all the way to the hardware. Most applications never need this, but databases call fsync() constantly. When your bank confirms a transaction, fsync() is part of why that confirmation means something.
The system call boundary — crossing costs time
This line is not just a diagram label — it represents a real hardware event. When your program makes a system call, the CPU physically switches from user mode to kernel mode to handle it, then switches back when finished.That switch is not free. It takes time. This is why programs try to make as few system calls as possible — instead of calling write() one byte at a time, they batch data and cross this line as rarely as possible.Your programming language handles this batching automatically through buffered I/O. You almost never think about it, but it is happening constantly behind the scenes.Above this line: your code controls what happens. Below it: the OS kernel has full authority and full hardware access.
Physical storage — the only layer that survives a power cut
Data is finally permanent here — written to the magnetic platter or flash cells. If the power goes out now, the data survives.But reaching this layer is slow — and that slowness is the entire reason all the buffering above exists. RAM operates in nanoseconds. A spinning hard drive needs milliseconds to physically move a read arm to the right track. That is a million-to-one speed difference.SSDs have no moving parts, but they are still far slower than RAM because of how flash memory cells are organized and erased. The physics are simply different at each layer.Buffering lets your program work at RAM speed almost all the time, only touching this slow layer in large, efficient batches — instead of one tiny write at a time..
The system call boundary — crossing costs time
This line is not just a diagram label — it represents a real hardware event. When your program makes a system call, the CPU physically switches from user mode to kernel mode to handle it, then switches back when finished.That switch is not free. It takes time. This is why programs try to make as few system calls as possible — instead of calling write() one byte at a time, they batch data and cross this line as rarely as possible.Your programming language handles this batching automatically through buffered I/O. You almost never think about it, but it is happening constantly behind the scenes.Above this line: your code controls what happens. Below it: the OS kernel has full authority and full hardware access.
Lorem ipsum dolor sit