A "dirty" page is one your program wrote to after it was loaded — RAM and disk now disagree about what's in it. The OS has to handle that differently than a page you only read.
Try this sequence:
- Load pages
0,1,2(click them on the disk row) — fills all 3 RAM frames. - Click on RAM page
0to write to it — it gets a red dirty border. No disk I/O happens yet, the write just lands in RAM. - Now load page
3— RAM is full, so something has to be evicted. Watch what happens depending on whether the evicted page is dirty or clean.
The two outcomes:
- Evicting a clean page is free. RAM and disk already agree, so the OS just drops the page from RAM. No I/O.
- Evicting a dirty page costs a write. The OS has to flush those bytes back to disk first — otherwise your change is lost forever — and only then can it reuse the frame for the new page. That's a write you triggered indirectly, at a time you didn't choose, possibly stalling whatever else needed that frame.
This is the real cost of letting the OS manage writes for you. It's convenient, but the timing of the flush is the kernel's call, driven by memory pressure — not by when your data actually needs to be durable.
That's exactly the gap a transaction log exists to close. If a process crashes between "wrote to the mmap'd page" and "OS got around to flushing it," that write never reached disk and is gone. A database that needs a durability guarantee — "once I tell you this is committed, it survives a crash" — can't wait for the kernel's eviction policy to decide when to flush. It writes to a separate append-only log with an explicit fsync() at commit time, so durability is on the database's schedule, not the page cache's.
Interactive simulation: click pages to load them into RAM, mark them dirty by writing, and watch clean pages evict instantly while dirty pages flush to disk first
Disk file — 6 pages
RAM — 3 frames. Click a RAM page to write to it (marks it dirty).
