Journaling — why, how it works — Hinglish notes

4.2.36 · Coding › Operating Systems

Journaling exist kyun karta hai?

Ye itna mushkil kyun hai? Ek disk sirf itni guarantee deta hai ki ek single sector write atomic hai. Ye guarantee nahi deta ki kai saari writes saath mein hoti hain. To ek "create file" aise interrupt ho sakti hai ki:

bitmap kehta hai block 12 use mein hai, lekin koi bhi inode uski taraf point nahi karta → lost block (leaked space), ya
directory ek aisi inode ki taraf point karta hai jo kabhi likhi hi nahi gayi → dangling pointer (corruption).

Purana fix (fsck): crash ke baad saari disk scan karo aur contradictions theek karo. Problem: time disk size ke saath badhta hai, crash se pehle kiye gaye kaam ke saath nahi. Ek 4 TB disk ko ghanton lag sakte hain.

Ye kaam kaise karta hai — core idea

Ek journal disk ka ek chota dedicated circular region hota hai. Rule (jise write-ahead logging kehte hain) ye hai:

Transaction lifecycle

Begin / write descriptor — ek record jo batata hai ki kaunse blocks badlenge.
Journal mein nayi data likhna (naye block contents ki copy).
COMMIT block likhna — ek marker jo kehta hai "poora transaction ab safely journal mein hai."
Checkpoint — baad mein, un journal blocks ko unke real in-place locations par copy karo.
Journal space free karo (circular log ko aage badhao).

Commit block kyun matter karta hai (poori trick): commit block sabse last mein likha jaata hai aur ye ek single small write hoti hai. Recovery ke dauran rule ye hai:

Modes: hum kya journal karte hain?

Worked Example 1 — file mein append karna, koi crash nahi

Operation: notes.txt mein 1 block append karna. Isme badlav chahiye: data block, inode (size + block pointer), aur bitmap.

Step	Action	Ye step kyun?
1	Journal mein descriptor "TX#7 touches inode 9, bitmap, block 50" likhna	Taaki recovery transaction ka scope jaane
2	Naya inode + bitmap (aur data agar data-mode hai to) journal mein likhna	Intended final state ko durably capture karta hai
3	TX#7 ke liye COMMIT likhna	Atomic "go" switch — ab replay allowed hai
4	Checkpoint: un blocks ko real inode/bitmap locations par copy karna	In-place change actually apply karta hai
5	Journal mein TX#7 ko free mark karna	Circular log space wapas lena

Koi crash nahi → real filesystem sahi se update hua, journal clean.

Worked Example 2 — commit se pehle crash

Crash step 2 ke baad lekin step 3 se pehle aata hai.

Reboot par, recovery journal scan karta hai, TX#7 mein koi COMMIT block nahi milta.
Discard kyun? In-place inode/bitmap kabhi touch hi nahi kiye gaye (step 4 chala hi nahi tha). On-disk filesystem bilkul wैसा hi hai jैसा append se pehle tha.
Result: append simply "hua hi nahi." Clean aur consistent. ✅

Worked Example 3 — commit ke baad, checkpoint ke dauran crash

Crash step 4 ke dauran aata hai (real inode likha ja chuka hai, bitmap abhi nahi).

Recovery TX#7 mein COMMIT block ke saath milta hai → replay: TX#7 ke saare journal blocks ko unke in-place homes par re-copy karo.
Pehle se likhe gaye inode ko dobara likhna safe kyun hai? Kyunki same final value do baar likhna = ek baar likhna. Ye idempotency hai — wo property jo WAL recovery ko correct banati hai.

Common Mistakes

Flashcards

Journaling kaunsi problem solve karta hai?

Crash consistency — ek single logical op ko kai disk writes chahiye; unke beech crash hone par filesystem corrupt ho jaata hai.

Write-Ahead Logging invariant kya hai?

Intent ko journal mein durably likhna zaroori hai pehle kisi bhi in-place (real) structure ko modify karne se.

Recovery ke dauran kaunsi single write decide karti hai ki transaction apply hoga ya nahi?

COMMIT block — present hai ⇒ replay; absent hai ⇒ discard.

Replay idempotent kyun hona chahiye?

Crash mid-checkpoint mein ho sakta hai, to same journal blocks dobara copy kiye ja sakte hain; same final values dobara likhna harmless hona chahiye.

Non-committed transaction ko discard karna safe kyun hai?

Kyunki in-place structures abhi tak touch hi nahi kiye gaye, to filesystem apni pre-transaction valid state mein hi hai.

Ext3/ext4 ke teen journaling modes batao.

journal (data), ordered (default, metadata + data-before-commit), writeback (sirf metadata, unordered).

Ordered mode writeback se zyada safe kyun hai?

Ye data blocks ko metadata commit karne se pehle flush karta hai, jo metadata ko stale/garbage data ki taraf point karne se rokta hai.

Kya journaling recent writes ki durability guarantee karta hai?

Nahi — sirf consistency. Unflushed buffered writes phir bhi lost ho sakti hain; durability ke liye fsync() use karo.

Journaling fsck se zyada fast recover kyun karta hai?

Recovery journal size (kaam jo chal raha tha) ke saath scale karta hai, total disk size ke saath nahi.

Journaling mein "checkpointing" kya hai?

Committed journal blocks ko unke real in-place locations par copy karna, phir us journal space ko free karna.

Recall Feynman: ek 12-saal ke bacche ko explain karo

Jab computer ek file save karta hai to use disk par kai alag-alag cheezein ek-ek karke badalni padti hain. Agar bich mein plug nikal jaaye, to file aadhi-badli aur tooti hui rah jaati hai. To real cheezein badalne se pehle, computer pehle ek chhoti si to-do list ek khaas notebook (journal) mein likhta hai aur bilkul end mein "DONE" ka stamp lagaata hai. Crash ke baad wo notebook padhta hai: agar koi kaam "DONE" stamp ke saath hai, to wo use saaf-saaf dubara karta hai; agar kisi kaam par DONE stamp nahi hai, to jaanta hai wo kaam kabhi shuru hi nahi hua tha, to bhool jaata hai. Is tarah real files kabhi aadhi-tooti nahi rehti.

Connections

File Systems — journaling ek filesystem ke upar layered property hai (ext3/ext4, NTFS, XFS).
Write-Ahead Logging — same technique jo Databases mein ACID atomicity & durability ke liye use hoti hai.
Atomicity — commit block all-or-nothing semantics provide karta hai.
fsync and Durability — consistency aur durability mein farq batata hai.
Copy-on-Write Filesystems — alternative crash-consistency strategy (ZFS/Btrfs) journaling ke comparison mein.
fsck — woh slower, whole-disk repair jo journaling replace karta hai.