Journaling — why, how it works: Visual walkthrough

4.2.36 · D2 · Coding › Operating Systems › Journaling — why, how it works

Hum ek choti si operation follow karenge — ek file mein ek block append karna — journal ke through, aur phir computer ko har khatarnak moment par deliberately crash karenge taaki dekh sakein kya hota hai.

Step 1 — "Disk" actually kya hota hai

WHAT. Kisi bhi journal ke exist karne se pehle, humein playground par agree karna hoga. Disk sirf numbered boxes ki ek lambi row hoti hai jise sectors (ya blocks) kehte hain. Har box bytes ka ek fixed chunk hold karta hai.

WHY start here. Baad ke har claim ("yeh write atomic hai", "yeh nahi hai") in boxes ke baare mein ek claim hai. Agar hum inhe picture nahi karte, toh "in-place" aur "journal" jaisi words ka koi matlab nahi.

PICTURE. Figure dekho. Grey strip disk hai. Zyaadatar boxes real filesystem hold karte hain: data blocks (tumhari file ke bytes), inode (ek chota record jo file ki size aur uske blocks kahan hain yeh store karta hai), aur bitmap (yes/no bits ki ek row jo mark karti hai kaunse blocks use mein hain). Daayein taraf ka ek chota region — blue colour mein — journal ke liye set aside hai.

Ek hardware fact jo hume diya gaya hai, aur sirf wahi ek:

Step 2 — Ek operation ko itne saare writes kyun chahiye (danger)

WHAT. Hamara single "append" actually teen alag box-writes hain: inode, bitmap, data block.

WHY it's dangerous. Step 1 se, ek baar mein sirf ek box safe hai. Toh ek crash teen writes ke beech ho sakta hai, ek mismatched combination chhod ke.

PICTURE. Figure teen writes ko teen arrows ke roop mein dikhata hai jo teen alag times $t_{1}, t_{2}, t_{3}$ par land karte hain. Laal lightning bolt ek crash mark karta hai jo bitmap write ke baad lekin inode write se pehle aaya.

Crash ne jo barbadi chhodhi usse padho:

$written bitmap: block 50 = used but never written inode: no pointer to 50$

Bitmap kehta hai block 50 liya hua hai.
Koi bhi inode uski taraf point nahi karta.
→ block 50 ek lost block hai — space jo na free hai na reachable. Corruption.

Yeh crash-consistency problem hai. Journaling sirf isse khatam karne ke liye exist karta hai. Notice karo ki hum "sirf writes ko better order karke" fix nahi kar sakte — koi bhi order mein ek fatal in-between moment hota hai.

Step 3 — Ek rule: pehle plan likho (WAL)

WHAT. Hum ek aisa rule introduce karte hain jo itna strong hai ki har fatal in-between moment khatam ho jaata hai: kisi bhi real box ko touch karne se pehle apna poora intent journal mein likho. Yeh Write-Ahead Logging hai (dekho Write-Ahead Logging).

WHY. Agar real structures tab tak untouched hain jab tak plan safe nahi ho jaata, toh "plan safe hone se pehle" crash karne par real filesystem bilkul waise hi rehta hai — perfectly valid. Hum danger ko ek throwaway region mein move kar dete hain.

PICTURE. Figure disk ko vertically split karta hai. Rule ko barrier $≺$ ke roop mein draw kiya gaya hai: journal side pe sab kuch pehle finish hona chahiye, tab hi real side pe kuch shuru ho sakta hai.

Yahi idea ek database ko bhi protect karta hai, jahan yeh transactions ki Atomicity enforce karta hai — journaling filesystem ka version hai iska.

Step 4 — Transaction: descriptor → data → COMMIT

WHAT. Journal ke andar hum ek blob nahi dump karte. Hum, strict order mein, teen tarah ke records likhte hain: ek descriptor, naye block copies, aur finally ek COMMIT block.

WHY this exact order. Har part ek recovery question ka jawab deta hai:

Descriptor kehta hai ki yeh transaction aakhirkar kaunse real boxes ko touch karega (iska scope).
New-block copies intended final contents hold karte hain.
COMMIT, jo bilkul last likha jaata hai aur ek single sector hota hai (Step 1: single sector = atomic!), ek one-bit "mere upar ka poora plan complete hai" hota hai.

PICTURE. Journal region ko write order mein left-to-right draw kiya gaya hai. COMMIT daayein taraf ka orange box hai — last cheez jo land karta hai.

$descriptor TX7: touches inode 9, bitmap, block 50 \to payload copies new inode | new bitmap | new data \to atomic go-switch COMMIT$

Kyunki COMMIT ek single sector hai, yeh khud all-or-nothing hai. Toh crash ke baad COMMIT ya poori tarah wahan hai ya poori tarah absent — kabhi half nahi. Woh crisp yes/no hi wo pivot hai jis par poori design tikti hai.

Step 5 — Checkpoint: sirf ab real boxes ko touch karo

WHAT. COMMIT safely down hone ke baad, hum checkpoint karte hain: har journal payload block ko uske real in-place home par copy karte hain. Phir hum circular journal ko advance karte hain taaki uska space reuse ho sake.

WHY afterwards. WAL rule (Step 3) ke hisaab se real boxes tab tak forbidden the jab tak plan durable nahi ho jaata. COMMIT prove karta hai ki plan durable hai, toh — aur sirf tabhi — real writes shuru ho sakti hain.

PICTURE. Green arrows payload ko blue journal se real inode/bitmap/data boxes mein le jaate hain. Journal ek ring hai: checkpoint ke baad uska slot free ho jaata hai aur agli transaction ke liye reuse hota hai (yahi reason hai ki yeh chhota rehta hai).

Step 6 — Recovery jab COMMIT MISSING ho (Step 4 khatam hone se pehle crash)

WHAT. Reboot. Journal scan karo. TX7 milo jiske paas koi COMMIT block nahi. Decision: isse discard karo.

WHY it's safe. Checkpoint (Step 5) kabhi nahi chala — woh sirf COMMIT ke baad chalta hai. Toh ek bhi real box touch nahi hua. Filesystem byte-for-byte apni pre-append state mein hai: valid.

PICTURE. Laal bolt journal ke beech mein strike karta hai, orange COMMIT land hone se pehle. Recovery woh gap dekhta hai jahan COMMIT hona chahiye tha, partial transaction throw away karta hai (grey cross-out), aur real side untouched hai (green check).

$COMMIT absent \Rightarrow real side untouched \Rightarrow discard, still consistent$

Append simply "kabhi hua hi nahi." Yahi exactly woh outcome hai jo hum Step 2 ki disaster se chahte the — na lost block, na dangling pointer.

Step 7 — Recovery jab COMMIT PRESENT ho (checkpoint ke dauran crash)

WHAT. Ab nasty case: crash Step 5 ke dauran — real inode likh gaya, lekin real bitmap nahi likha. Reboot par, TX7 ke paas apna COMMIT hai. Decision: replay — TX7 ke saare payload ko unke homes par re-copy karo.

WHY already-written inode ko re-write karna harmless hai. Replay same final values likhta hai jo payload hold karta hai. Same value dobaara likhna ek baar likhne ke barabar hai — yeh idempotency hai.

PICTURE. Left half: crash ne checkpoint ko half-done pakda (inode ✓, bitmap ✗). Right half: replay dono ko re-copy karta hai; inode simply identical value se overwrite ho jaata hai, bitmap finally fill ho jaata hai. End state = fully applied, consistent.

Step 8 — Degenerate & edge cases (taaki kuch surprise na kare)

WHAT. Hum woh corners tick off karte hain jo smart reader puchega.

WHY. Ek rule jis par tum poori tarah trust nahi kar sakte, worthless hai. Neeche har case Step 7 ke rule ki do branches mein se ek mein land karna chahiye.

PICTURE. Ek chota case-table figure har crash moment ko uske outcome par map karta hai.

Crash moment	COMMIT state	Action	Result
Abhi kuch nahi likha	absent	discard (kuch karna nahi)	pre-state, valid
Mid-payload (Step 4)	absent	discard	pre-state, valid
Jis waqt COMMIT land ho raha ho	atomic ⇒ fully there or fully gone	replay or discard	kabhi "half" nahi
COMMIT ke baad, checkpoint se pehle	present	replay whole TX	applied, valid
Mid-checkpoint (Step 7)	present	replay whole TX	applied, valid
Checkpoint ke baad, free se pehle	present	replay (idempotent, no harm)	applied, valid

Recall Kya journaling tumhara

unflushed data save karta hai? Nahi. Yeh consistency guarantee karta hai, RAM mein baithe writes ki durability nahi. Uske liye tumhe fsync chahiye. Ek crash last kuch seconds ki writes guma sakta hai — lekin filesystem ko kabhi corrupt nahi chhod sakta.

Ek-picture summary

Upar sab kuch ek single timeline mein collapse ho jaata hai: journal bharta hai → COMMIT land karta hai → real boxes likhti hain → journal free hoti hai, aur recovery rule off karta hai ki COMMIT line cross ki ya nahi.

Orange COMMIT line se pehle: crash ka matlab hai discard, real side untouched.
Uske baad: crash ka matlab hai replay, idempotency use safe banata hai.
COMMIT line all-or-nothing boundary hai — ek vertical stroke mein poori derivation.

Ek neighbouring design, Copy-on-Write Filesystems, usi guarantee tak alag tarah pahunchti hai — in-place overwrite kabhi na karke — lekin sawaal jo woh answer karti hai bilkul same hai: crash ko kabhi mid-change mat pakadne do.

Recall Feynman: poora walkthrough simple words mein

Disk ek waqt mein sirf ek chota box safely badal sakti hai, lekin ek file save karne ke liye teen boxes chahiye. Agar unke beech bijli gire, toh broken file milti hai. Toh computer pehle poora plan likhta hai — "in teen boxes ko yeh values de do" — ek choti scratchpad mein, aur bilkul end mein ek quick pen-stroke se DONE stamp lagata hai (woh stroke itna chhota hai ki ya toh hota hai ya nahi hota). DONE stamp ke baad hi real boxes change hote hain. Agar stamp se pehle bijli gire, plan throw away ho jaata hai aur real file untouched rehti hai — save hua hi nahi. Agar stamp ke baad bijli gire, reboot par computer DONE stamp dekhta hai, poora plan scratchpad se re-do karta hai, aur same values dobaara likhne se kuch nahi badalta. Toh file kabhi half-broken nahi rehti. Bas itna hi.

Recall Quick self-test

Kaun sa single write decide karta hai replay vs discard? ::: COMMIT block — present ⇒ replay, absent ⇒ discard. Non-committed transaction discard karna safe kyun hai? ::: Checkpoint kabhi nahi chala, toh real in-place structures kabhi touch nahi hue. COMMIT write ke dauran crash hona dangerous kyun nahi? ::: COMMIT ek sector hai; single-sector writes atomic hote hain, toh woh fully present ya fully absent hoga. Kaunsi property replay ko already-written blocks re-copy karne ki permission harmlessly deti hai? ::: Idempotency — same final value do baar likhna ek baar likhne ke barabar hai.