Exercises — Journaling — why, how it works

Consistency ::: filesystem ke structures kabhi ek doosre se contradict nahi karte (koi block do files ka nahi, koi directory kisi khaali jagah point nahi karti). Durability ::: ek write jise tumhe "succeeded" bataya gaya woh power cut mein bhi bachti hai. Consistency se alag! Dekho fsync and Durability. Idempotent ::: do baar karna wahi result deta hai jo ek baar karna deta hai — ek box mein value $8$ likhna, phir $8$ likhna, $8$ hi rehta hai.

COMMIT block. Yeh sab se aakhir mein likha jaata hai aur yeh ek chhota sa single sector write hota hai (disks guarantee karti hain ki ek sector atomic hota hai). Recovery rule: commit present ⇒ replay; commit absent ⇒ discard. Isliye parent note isse "the atomic go switch" kehta hai.

WAL invariant: ==intent durably journal par hona chahiye pehle koi bhi in-place (real) structure touch ho== — likha jaata hai $\text{journal}\prec \text{in-place}$, jahan $\prec$ ka matlab hai "strictly completes before". (A) isko obey karta hai (journal first). (B) isko violate karta hai — agar (B) ke do steps ke beech crash aa jaaye, toh real inode pehle se hi toot chuka hai aur journal mein koi record nahi hai usse theek karne ke liye. Dekho Write-Ahead Logging.

Ordered mode sirf metadata journal karta hai: inode aur bitmap → 2 structures journal mein jaate hain. Data block journal mein nahi jaata; instead isse disk par commit block se pehle force kiya jaata hai. Isse inode garbage point karne se bachta hai. Parent note mein modes table dekho the parent note.

Transaction ko discard karo. Kyunki commit missing hai, recovery trust nahi kar sakti ki saare $N$ metadata blocks durably pahunche — woh poori cheez ko kabhi-commit-nahi-hua treat karti hai. Khaas baat, checkpoint step (journal → in place copy karna) nahi hua tha, isliye real inode/bitmap kabhi touch nahi hue. Filesystem byte-for-byte apni pre-transaction state mein hai → consistent hi hai. Append simply "hua hi nahi." ✅

Megabytes mein convert karo: $D=4\text{TB}=4\times 10^6\text{MB}$. (a) $t_{\text{fsck}}=\frac{D}{R}=\frac{4\times 10^6}{200}=20000\text{s}\approx 5.56\text{hours}$. (b) $t_{\text{journal}}=\frac{J}{R}=\frac{128}{200}=0.64\text{s}$. (c) Factor $=\frac{t_{\text{fsck}}}{t_{\text{journal}}}=\frac{20000}{0.64}=31250\times$ faster. Point: journal recovery kaam jo chal raha tha uske saath scale karta hai ($J$, fixed), jabki fsck total disk size ke saath ($D$). Badi disks fsck ko aur bura banati hain lekin journaling par koi asar nahi.

Reader blocks 40–41 ka stale/garbage content dekhta hai — yahan, kisi aur ka purana password data. Committed metadata legitimately unhi blocks ko point karta hai, lekin intended naya data kabhi aya hi nahi. Yeh ek real security/integrity leak hai. Ordered mode ka fix: yeh data blocks ko disk par force karta hai pehle metadata commit se (data $\prec$ metadata-commit). Toh agar metadata durable hai, toh jis data ko woh point karta hai woh guaranteed pehle se durable hai — stale blocks expose hone ka koi window nahi. Isliye ordered mode default sweet spot hai.

Useful payload $=8\text{MB}+16\text{KB}=8.015625\text{MB}$ (kyunki $16\text{KB}=0.015625\text{MB}$). Data mode mein har byte do baar likha jaata hai — ek baar journal mein, ek baar in place: $\text{total}=2\times 8.015625=16.03125\text{MB}.$ Write amplification $=\frac{16.03125}{8.015625}=2.0\times$. Synthesis point: yahi exact 2× cost hai jo full data mode ko "safest, slowest" banati hai, aur isliye ordered mode banaya gaya — woh sirf $16\text{KB}$ metadata journal karta hai, toh data ka amplification $1\times$ hota hai. Yahi tension Databases mein Write-Ahead Logging ke saath study ki jaati hai.

Doosri copy se pehle, disk inode.size $=8192$ (pehle checkpoint se). Journal ki inode.size copy bhi $8192$ hai. Re-copying $8192$ ke upar $8192$ likhta hai → value unchanged rehti hai. Bitmap, jo miss hua tha, ab usi replay se bit[50] $=1$ paata hai. Final state: inode.size $=8192$, bitmap.bit[50] $=1$ — exactly committed intent. General property: idempotency — committed transaction ko kitni bhi baar replay karna ek baar replay karne jaisa hi final state deta hai. Yahi crash-during-recovery ko safe banata hai: recovery khud crash ho sakti hai aur dobara run ho sakti hai bina kisi limit ke. Dekho Atomicity.

OS issue karta hai: (1) journal metadata, (2) commit block, (3) checkpoint in place — sahi order mein. Lekin agar disk reorder kare aur commit block ko platter par pehle push kare journal metadata se, toh crash ek committed transaction chod sakti hai jiska logged data missing hai. Recovery commit dekhti hai, trust karti hai, replay karti hai — aur garbage/incomplete blocks in place copy karti hai. Corruption, perfect OS ordering ke bawajood. Root cause: disk ki apni cache ne woh durability boundary tod di jo OS ne assume ki thi. Fix: cache flush / write barrier — OS ko fsync() call karni chahiye (ya FLUSH/FUA barrier issue karna chahiye) journal data likhne ke baad aur fir commit ke baad, disk ko force karte hue ki woh har group ko durably persist kare agle ke shuru hone se pehle. Honest flush primitive ke bina, WAL ka $\prec$ ordering physical media par enforce nahi ho sakta. Dekho fsync and Durability.

Journaling: in place update karo, lekin pehle intent ek side journal mein likho; recovery replay ya discard karta hai. Full data mode mein yeh data do baar likhta hai (journal + in place). Copy-on-write: kabhi overwrite mat karo; naya data fresh blocks par likho, phir atomically ek single root pointer ko naye tree par flip karo — purana version valid rehta hai flip hone tak. Dekho Copy-on-Write Filesystems. CoW kabhi user data do baar nahi likhta — woh har naye block ko exactly ek baar naye location par likhta hai aur sirf re-point karta hai. Journaling ka data mode inherently double-write karta hai; yahi fundamental trade hai jo dono designs karte hain.

Journaling nahi tooti. Iska promise consistency hai (structures kabhi contradict nahi karte), nahi durability of un-synced buffered writes. Returned write() ka sirf matlab hai "kernel RAM buffer mein copy kiya," "platter par hai" nahi. Kyunki woh data kisi committed journal transaction tak kabhi nahi pahuncha, recovery ke paas correctly kuch replay nahi hai — aur on-disk filesystem perfectly consistent hai, sirf 500 KB ke bina. Program ko kya karna chahiye tha: write() ke baad fsync(fd) call karo taaki buffered data (aur uska journal transaction) durably disk par ja sake ise saved maanne se pehle. Consistency filesystem ka kaam hai; specific bytes ki durability application ka kaam hai, fsync() ke through. Dekho fsync and Durability.

Woh write jo replay-vs-discard decide karti hai woh hai COMMIT block. WAL journal write ko strictly in-place modification se pehle order karta hai. Recovery safe hai dobara run karne ke liye kyunki replay idempotent hai. Ordered mode sirf metadata journal karta hai lekin data ko metadata commit se pehle force karta hai. Journaling consistency guarantee karta hai, durability nahi; baad wale ke liye fsync use karo.