Write-through sends every write to the backend and keeps nothing at risk. Write-back holds writes in the cache and sends the distinct keys once per flush, which is a coalescing ratio on any trace with repeats. What it buys is fewer backend writes; what it costs is a loss window, and both come off the same trace.
Core ideas
One rule each, and then a number that only exists for the second of them: what is lost if the process dies.
The write goes to the backend and to the cache, and it is not acknowledged until the backend has it. Backend write rate equals the application write rate exactly. Nothing is ever only in the cache, so a crash loses nothing and the loss window is zero.
The write goes to the cache and is acknowledged; the cache flushes dirty entries to the backend periodically. Repeated writes to the same key inside one flush window collapse into one backend write, so the backend sees the distinct keys per window. On A B A C A B A D A B flushed every five writes, that is 6 backend writes for 10 application writes.
Whatever is dirty when the process dies is gone. The right measure is the largest dirty set a flush interval ever holds, not the average: an average loss window is not what a crash takes. On that trace it is 3 keys, which at 4 kB each is 12.00 kB, held for the 5.0 ms a flush interval lasts at 1 000 writes a second.
The material
The rules, the counting, and why the trace decides whether write-back is worth anything at all.
Under write-through, every write is applied to the cache and to the backend before it is acknowledged. Under write-back, a write is applied to the cache, marked dirty and acknowledged; dirty entries are written to the backend on a periodic flush.
The coalescing ratio of a trace under write-back is the number of writes divided by the number of distinct keys written, counted per flush window. It is 1 when every write in a window is to a different key, and it is the window length when they are all to the same key.
Both policies leave the cache correct. The difference is entirely about the backend: how many writes it receives, how quickly it learns about them, and what happens to the ones it has not learned about yet.
Take the write trace A B A C A B A D A B and flush every five writes. The first window is A B A C A: five writes, three distinct keys, so two writes to A are coalesced away. The second is B A D A B: five writes, three distinct keys again. Ten writes, six backend writes, a ratio of 5/3.
Widen the flush window to ten writes and the whole trace becomes one window: four distinct keys, a ratio of 5/2, and the backend sees 400 writes a second instead of 600. The dirty set grows to 4 keys and 16.00 kB, held for 10.0 ms. That is the trade in its entirety, and both ends of it moved together.
The ratio is a property of the workload, not of the policy. A trace in which every write is to a different key inside its window — A B C D E F G H I J — coalesces nothing at all: write-back sends ten writes, exactly as write-through does, and still carries the loss window. A trace of one key repeated ten times coalesces to one per window and buys a ratio of five.
So “write-back is faster” is not a general claim. It is a claim about a workload with repeated writes to the same keys inside a flush interval, and if you do not have that, write-back is a loss window with no compensating gain. Run your own trace before choosing.
The bytes at risk are the largest dirty set times the object size, and the exposure lasts a flush interval — w/λ_w seconds, for a window of w writes at λ_w writes a second. At 1 000 writes a second and a five-write window that is 5.0 ms, which sounds negligible until you multiply it by the number of processes you run and the number of times a year each of them dies.
The honest statement of the trade is arithmetic on both numbers at once: a flush window k times wider improves the ratio by at most k and grows both the dirty set and the exposure time. Whether the trade is acceptable is a durability question, and Availability and Failure is where losing things gets priced.
Interactive
The coalescing ratio, and the loss window it is bought with
Method
Count the distinct keys per window first. If the ratio is one, there is nothing to discuss.
A sequence of written keys in order, and how many writes a flush covers. The flush interval is usually configured in time; convert it with the write rate, since w = λ_w · flush seconds.
Not distinct keys overall: per window. A key written in two different windows is two backend writes. This is the only counting in the lesson and it is where the ratio comes from.
writes ÷ distinct is the ratio, and λ_w × (distinct/writes) is what the backend actually receives. On this trace, 1 000 writes a second becomes 600.
Peak, not mean: a crash takes whatever was dirty at that instant, and the instant is not chosen kindly. Multiply by the object size and state the exposure as bytes over a flush interval.
Ten writes, two windows, and then the same trace at a wider flush so that both ends of the trade move where you can see them.
Doubling the flush window improved the ratio from 5/3 to 5/2 — a further 200 writes a second off the backend — and took the exposure from 12.00 kB over 5.0 ms to 16.00 kB over 10.0 ms. Both numbers moved, and a proposal that mentions only the first is not a proposal.
For a faded rehearsal, run A B C D E F G H I J at a flush of five. The supplied first move is to count the distinct keys in the first window before computing anything; do that, then state the ratio, the backend write rate and the bytes at risk, and say in one sentence what write-back has bought on this trace.
The lab marks every repeated write inside a window as coalesced away and counts the rest, so you can see which writes the ratio is made of. Try the one-hot-key trace and the all-distinct trace before deciding what you believe about write-back.
You should be able to count distinct keys per flush window off a trace, convert that into a coalescing ratio and a backend write rate, compute the bytes at risk from the peak dirty set and the exposure from the flush interval, and say what a wider flush does to all four numbers.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.