Crash consistency — fsck, journaling আর copy-on-write file system

১ · একটি block যোগ, তিনটি লেখা — crash consistency সমস্যা

পর্ব ৪৩-এ দেখেছেন, একটি সাধারণ Unix-ধাঁচের file system ডিস্ককে কয়েকটি অংশে ভাগ করে: superblock (পুরো file system-এর হিসাব), inode bitmap আর data bitmap (কোন inode আর কোন block খালি), inode-এর টেবিল, আর data block. একটি ফাইলের নাম, আকার, মালিক আর তার data block-গুলোর ঠিকানা থাকে তার inode-এ। এই সব হিসাবকে একসাথে বলে metadata — “ডেটা সম্পর্কে ডেটা”।

এবার একটি অতি সাধারণ কাজ ভাবুন: notes.txt ফাইলের শেষে লিখে এমনভাবে ডেটা যোগ করা হলো যে নতুন একটি block লাগবে। File system-কে তিনটি জায়গায় লিখতে হবে:

1. Inode (I): ফাইলের আকার বাড়ানো আর নতুন block-এর ঠিকানা (ধরা যাক block 5) যোগ করা।
2. Data bitmap (B): block 5-কে “ব্যবহৃত” চিহ্নিত করা।
3. Data block (D): block 5-এ আসল নতুন লেখাটি রাখা।

তিনটি লেখা ডিস্কের তিনটি আলাদা জায়গায়। ডিস্ক সাধারণত শুধু একটি sector (৫১২ বাইট বা ৪ KiB) লেখাকে অবিভাজ্যভাবে (atomically) শেষ করার চেষ্টা করে — তিনটি আলাদা জায়গার লেখাকে একসাথে “সব নয়তো কিছুই না” করার কোনো উপায় তার নেই। আর kernel এগুলো page cache-এ জমিয়ে রাখে, পরে writeback-এর সময় যেকোনো ক্রমে পাঠায়; ডিস্ক নিজেও ক্রম বদলাতে পারে। এর মাঝে যদি বিদ্যুৎ চলে যায় (লোডশেডিং, UPS-এর ব্যাটারি শেষ) বা kernel panic হয়, ডিস্কে পৌঁছাবে তিনটির যেকোনো উপসেট। File system-কে এমন অবস্থায় রেখে যাওয়ার সমস্যাকেই বলে crash consistency সমস্যা।

নিচের ডায়াগ্রামে inode 12 (notes.txt) এখন ১টি block-এর (block 4). নতুন block হবে 5; block 5-এ এই মুহূর্তে আছে আগের কোনো মুছে ফেলা ফাইলের পুরোনো জঞ্জাল। আটটি সম্ভাব্য অবস্থা (তিনটি লেখার প্রতিটি পৌঁছেছে বা পৌঁছায়নি, ২^৩ = ৮) একে একে দেখুন:

1crash before any write2only D reached disk3only I reached disk4only B reached disk5I + B, not D6I + D, not B7B + D, not I8I + B + D (all three)

২ · fsck — crash-এর পরে পুরো ডিস্ক মিলিয়ে দেখা

প্রথম যুগের Unix file system আর MS-DOS-এর FAT প্রথম দর্শন মানত: crash হলে হোক, পরের বার চালু হওয়ার সময় একটি প্রোগ্রাম পুরো file system ঘেঁটে অসংগতি খুঁজে ঠিক করবে। Unix-এ এই প্রোগ্রামের নাম fsck (file system check); Windows-এ সমতুল্য কাজ করে chkdsk. fsck একটি মূলনীতি মানে: metadata-কে পরস্পরের সাথে মেলানো. সে যা যা দেখে:

Linux-এর ext2/3/4-এর fsck প্রোগ্রাম e2fsck এই কাজগুলো পাঁচটি ধাপে (pass) করে, আর চালানোর সময় সেগুলোর নামই ছাপে — inode, block আর আকার; directory-র গঠন; directory-র সংযোগ; reference count; আর শেষে group-এর সারাংশ (bitmap আর গণনা)। এটি একটি উদাহরণ সেশন (root লাগে, আর mount করা file system-এ কখনো চালাবেন না):

$ sudo umount /dev/sdb1
$ sudo e2fsck -f /dev/sdb1
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  +5
Fix<y>? yes
/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 12/65536 files (0.0% non-contiguous), 12753/262144 blocks

fsck-এর দুটি মৌলিক সমস্যা

এক, সে ধীর — আর ডিস্ক যত বড়, তত ধীর। একটি block-এর অমিল খুঁজতে fsck-কে পুরো inode টেবিল আর সব ফোল্ডার পড়তে হয়, কারণ সে জানে না crash-এর আগে কোন কাজ চলছিল। কাজের সময় বদলের আকারের অনুপাতে নয়, file system-এর আকারের অনুপাতে। ১৯৮০-এর দশকে কয়েকশো MB-র ডিস্কে এটি কয়েক মিনিট; আজ কয়েক TB-র ডিস্কে, বিশেষত লাখ লাখ ফাইলসহ, ঘণ্টা ছাড়াতে পারে।

দুই, সে শুধু metadata-কে পরস্পরের সাথে মেলায় — সত্যের সাথে নয়। উপরের ধাপ ৫-এর (I + B) ক্ষেত্রে inode আর bitmap মেলে, তাই fsck সন্তুষ্ট — অথচ ফাইলে জঞ্জাল। যেখানে লেখা হারিয়েছে, সেখানে fsck শুধু leak বন্ধ করে, লেখা ফেরায় না। fsck-এর লক্ষ্য file system-কে আবার ব্যবহারযোগ্য করা, ব্যবহারকারীর ডেটা বাঁচানো নয়।

৩ · Journaling — আগে খাতায় লিখুন, তারপর কাজ

ডেটাবেসের জগতে একটি পুরোনো কৌশল আছে: write-ahead logging (WAL) — কোনো বদল আসল জায়গায় করার আগে একটি log-এ লিখে রাখা, যাতে crash-এর পর log দেখে কাজটি শেষ বা বাতিল করা যায়। DBMS কোর্সের Recovery পর্বে WAL, LSN, checkpoint আর ARIES বিস্তারিত আছে; এখানে আমরা দেখব file system কীভাবে একই ধারণা আরও সরলভাবে ব্যবহার করে। File system-এ এর নাম journaling, আর log-টির নাম journal — ডিস্কের একটি নির্দিষ্ট এলাকা (ext4-এ সাধারণত একটি লুকানো ফাইল, inode 8).

একটি transaction-এর চারটি ধাপ, আর recovery

আগের উদাহরণটি (I, B, D) data journaling দিয়ে ধরুন — অর্থাৎ data-ও journal-এ যায়। একটি journal transaction এভাবে চলে:

1. Journal write: journal-এ লেখা হয় একটি শুরু-চিহ্ন TxB (transaction begin; এতে transaction নম্বর আর কোন block-গুলো আসল কোথায় যাবে তার তালিকা), তারপর I, B, D-এর পুরো নতুন কপি।
2. Journal commit: এবার একটি ছোট commit block TxE লেখা হয়। এটি একটি sector-এর লেখা, তাই atomic. TxE ডিস্কে বসার মুহূর্তটিই transaction-এর “committed” হওয়ার মুহূর্ত।
3. Checkpoint: I, B, D-কে তাদের আসল জায়গায় (inode টেবিল, bitmap, block 5) লেখা। একে বলে checkpoint.
4. Free: checkpoint শেষ হলে journal-এর ওই অংশ আর দরকার নেই — journal-এর superblock-এ লিখে জায়গাটি মুক্ত করা হয়।

আর crash-এর পর recovery: বুট-এর সময় file system journal পড়ে। যে transaction-এর TxB আর TxE দুটোই আছে, সেগুলোর block আসল জায়গায় আবার লেখা হয় — একে বলে replay (redo logging). যার TxE নেই, সেটি বাদ — যেন কখনো শুরুই হয়নি। Replay একাধিকবার হলেও ক্ষতি নেই, কারণ প্রতিবার একই পূর্ণ block-কপি একই জায়গায় বসে — কাজটি idempotent. তাই recovery-র মাঝেও crash হলে আবার শুরু থেকে replay করলেই চলে।

নিচের ডায়াগ্রাম ext4-এর ডিফল্ট মোডে (ordered — পরের অংশে বিস্তারিত) একই কাজটির জীবনচক্র দেখায়। Transaction নম্বর 41; journal-এ I′ আর B′ মানে inode আর bitmap-এর নতুন কপি। প্রতিটি ধাপে ভাবুন: “ঠিক এখানে বিদ্যুৎ গেলে কী হবে?”

1start handle (in memory)2write D -> block 5, wait3journal: TxB(41), I', B'4FLUSH disk cache5journal: TxE(41) with FUA6checkpoint: I', B' -> home7free: advance journal tail

Batching, circular log আর revoke record

Batching: প্রতিটি write()-এর জন্য আলাদা transaction হলে একই inode বা bitmap block বারবার journal-এ লেখা হতো। তাই ext3/ext4 মেমরিতে একটি বড় compound transaction খোলা রাখে, সব বদল তাতে জমায়, আর কিছুক্ষণ পরপর (ext4-এ ডিফল্ট প্রতি ৫ সেকেন্ডে, commit=5) বা কেউ fsync চাইলে একবারে commit করে। একই block-এর দশটি বদলের জন্য journal-এ একটিই কপি যায়।

Circular log: journal-এর আকার সীমিত (কয়েক দশ MB থেকে ১ GiB-এর মতো)। তাই এটি একটি circular log — শেষে পৌঁছালে আবার শুরুতে ফিরে লেখে, ঠিক যেমন circular queue. Journal-এর নিজের superblock মনে রাখে সবচেয়ে পুরোনো এখনো-checkpoint-না-হওয়া transaction (tail) কোথায়। Journal ভরে গেলে নতুন transaction অপেক্ষা করে, যতক্ষণ না পুরোনোগুলোর checkpoint শেষ হয়ে জায়গা খালি হয়।

Revoke record: ধরুন metadata-journaling মোডে একটি ফোল্ডারের block 1000 (metadata) journal-এ লেখা হয়েছিল। পরে ফোল্ডারটি মুছে block 1000 একটি সাধারণ ফাইলের data হিসেবে আবার ব্যবহৃত হলো — data journal-এ যায় না। এবার crash: recovery journal-এর পুরোনো ফোল্ডার-কপিটি replay করলে নতুন ফাইলের ডেটা মুছে যাবে! তাই block মুক্ত হলে journal-এ একটি revoke record লেখা হয় — block 1000-এর আগের কপি আর replay করা যাবে না। Recovery আগে সব revoke সংগ্রহ করে, তারপর replay-র সময় সেগুলো বাদ দেয়।

৪ · data=journal, ordered, writeback — কোন মোডে কী নিশ্চয়তা

Data journaling-এ প্রতিটি data block দুবার লেখা হয় — একবার journal-এ, একবার আসল জায়গায়। বড় ফাইল লেখায় ডিস্কের কাজ প্রায় দ্বিগুণ। অথচ data block-এর সংখ্যা metadata-র চেয়ে অনেক বেশি। তাই বেশিরভাগ journaling file system শুধু metadata journal করে — একে বলে metadata journaling. প্রশ্ন তখন একটাই: data block কখন লেখা হবে, metadata-র commit-এর আগে না পরে? Linux-এর ext3 আর ext4 এই উত্তর অনুযায়ী তিনটি মোড দেয়, mount-এর সময় data= বিকল্পে:

লক্ষ করুন, তিন মোডেই metadata crash-এর পর consistent থাকে — fsck লাগে না। পার্থক্য শুধু data-র নিশ্চয়তায়। Ordered মোডের নিয়মটি আসলে আগের ছকের “I + B, D নয়” (garbage) ক্ষেত্রটি নিষিদ্ধ করে: metadata কখনো এমন block দেখাবে না, যেখানে নতুন data এখনো বসেনি। Writeback মোডে সেই নিষেধ নেই — তাই সেটি দ্রুত, কিন্তু জঞ্জাল দেখা যেতে পারে।

লেখার সংখ্যা — পরীক্ষার পরিচিত হিসাব

একটি block-এর append (I, B, D, প্রতিটি 4 KiB), journal-এর TxB আর TxE প্রতিটি ১ block ধরে:

• Journal নেই: I, B, D = ৩টি লেখা — কিন্তু crash-নিরাপত্তা নেই।
• data=journal: journal-এ TxB + I + B + D + TxE = ৫, checkpoint-এ I + B + D = ৩ — মোট ৮টি.
• data=ordered: D (আসল জায়গায়) ১ + journal-এ TxB + I + B + TxE = ৪ + checkpoint-এ I + B = ২ — মোট ৭টি.
• data=writeback: সংখ্যা ordered-এর মতোই ৭টি; পার্থক্য শুধু ক্রমে — D যেকোনো সময় যেতে পারে।

১ GB-র ভিডিও লেখায় data=journal প্রায় ২ GB লেখে। আবার উল্টো দিকও আছে: অনেক ছোট synchronous লেখার (যেমন মেইল সার্ভার) ক্ষেত্রে data=journal কখনো দ্রুত হয়, কারণ journal-এ লেখা পরপর (sequential), আর fsync শুধু journal-এর লেখা শেষ হলেই ফিরতে পারে।

Simulator — প্রতিটি সম্ভাব্য মুহূর্তে crash

নিচের প্রোগ্রাম এই পর্বের মূল যুক্তিটি যন্ত্রের মতো যাচাই করে। প্রথম অংশে journal নেই: তিন লেখার আটটি উপসেটের প্রতিটি ডিস্কে আছে ধরে ফল শ্রেণিভুক্ত করে। দ্বিতীয় অংশে ordered journaling: পাঁচটি লেখার ক্রমে (D, journal-এর TxB+I+B যাকে J বলা হলো, TxE, তারপর checkpoint-এ I আর B) প্রতিটি ধাপের পরে crash ঘটিয়ে recovery চালায়। তৃতীয় অংশে FLUSH নেই, আর ডিস্ক TxE-কে journal-এর বাকি লেখার আগে বসিয়েছে:

// Append one block: inode I (pointer + size), data bitmap B, data block D
function classify(s) {                  // s = which writes reached their home location
  if (s.I && s.B && s.D) return "consistent (new file)";
  if (s.I && !s.B) return "CORRUPT: inode uses a block the bitmap calls free" + (s.D ? "" : " + garbage");
  if (s.I) return "GARBAGE: metadata agrees, block holds old junk";
  if (s.B) return "LEAK: block marked used, no inode owns it";
  return "consistent (old file)" + (s.D ? ", new data lost" : "");
}
const has = (done, k) => done.includes(k);
const home = done => ({ I: has(done, "I"), B: has(done, "B"), D: has(done, "D") });

console.log("1) No journaling - the disk may finish any subset before the crash:");
for (let m = 0; m < 8; m++) {
  const done = ["I", "B", "D"].filter((k, i) => m & (4 >> i));
  console.log("   on disk " + (done.join("+") || "none").padEnd(6) + "-> " + classify(home(done)));
}

function recover(done) {                // journal recovery after reboot
  const s = home(done);
  if (!has(done, "TxE")) return "discard -> " + classify(s);
  if (!has(done, "J")) return "replay  -> CORRUPT: journal slots held junk, copied over I and B";
  s.I = s.B = true;                     // replay copies I and B from the journal
  return "replay  -> " + classify(s);
}
function run(title, steps) {
  console.log(title);
  for (let k = 0; k <= steps.length; k++) {
    const done = steps.slice(0, k);
    console.log(("   crash after " + k + " [" + (done.join(",") || "-") + "]").padEnd(31) + recover(done));
  }
}
run("2) Ordered journaling: D, J = TxB+I+B, FLUSH, TxE, then checkpoint I, B", ["D", "J", "TxE", "I", "B"]);
run("3) No FLUSH - the disk reordered TxE ahead of the journal blocks", ["D", "TxE", "J", "I", "B"]);

1) No journaling - the disk may finish any subset before the crash:
   on disk none  -> consistent (old file)
   on disk D     -> consistent (old file), new data lost
   on disk B     -> LEAK: block marked used, no inode owns it
   on disk B+D   -> LEAK: block marked used, no inode owns it
   on disk I     -> CORRUPT: inode uses a block the bitmap calls free + garbage
   on disk I+D   -> CORRUPT: inode uses a block the bitmap calls free
   on disk I+B   -> GARBAGE: metadata agrees, block holds old junk
   on disk I+B+D -> consistent (new file)
2) Ordered journaling: D, J = TxB+I+B, FLUSH, TxE, then checkpoint I, B
   crash after 0 [-]           discard -> consistent (old file)
   crash after 1 [D]           discard -> consistent (old file), new data lost
   crash after 2 [D,J]         discard -> consistent (old file), new data lost
   crash after 3 [D,J,TxE]     replay  -> consistent (new file)
   crash after 4 [D,J,TxE,I]   replay  -> consistent (new file)
   crash after 5 [D,J,TxE,I,B] replay  -> consistent (new file)
3) No FLUSH - the disk reordered TxE ahead of the journal blocks
   crash after 0 [-]           discard -> consistent (old file)
   crash after 1 [D]           discard -> consistent (old file), new data lost
   crash after 2 [D,TxE]       replay  -> CORRUPT: journal slots held junk, copied over I and B
   crash after 3 [D,TxE,J]     replay  -> consistent (new file)
   crash after 4 [D,TxE,J,I]   replay  -> consistent (new file)
   crash after 5 [D,TxE,J,I,B] replay  -> consistent (new file)

৫ · ডিস্কের cache “মিথ্যা” বলতে পারে — FLUSH, FUA আর barrier

Journaling-এর পুরো যুক্তি একটি অনুমানের ওপর দাঁড়িয়ে: “ডিস্ক যখন বলে লেখা শেষ, তখন লেখাটি সত্যিই স্থায়ী।” আধুনিক ডিস্কে এটি ডিফল্টভাবে সত্য নয়। হার্ড ডিস্ক আর SSD দুটোরই ভেতরে থাকে একটি volatile write cache. ডিস্ক লেখাটি এই cache-এ রেখেই “শেষ” জানিয়ে দেয় (একে বলে write-back caching), আর পরে নিজের সুবিধামতো ক্রমে আসল মাধ্যমে লেখে। বিদ্যুৎ চলে গেলে cache-এর লেখা হারায়, আর যেটুকু বসেছে সেটুকু হয়তো kernel যে ক্রমে পাঠিয়েছিল সেই ক্রমে নয়।

তাই ক্রম বজায় রাখতে kernel ডিস্ককে দুটি বিশেষ আদেশ দেয়:

• Cache flush (FLUSH): এ পর্যন্ত যত লেখাকে ডিস্ক “শেষ” বলেছে, সব স্থায়ী মাধ্যমে লিখে তবেই উত্তর দেওয়ার আদেশ। SATA-তে FLUSH CACHE, NVMe-তে Flush আদেশ।
• FUA (Force Unit Access): একটি নির্দিষ্ট লেখার সাথে লাগানো চিহ্ন — “এই লেখাটি cache-এ রেখে নয়, স্থায়ী মাধ্যমে লিখে তবেই শেষ বলবে।”

Journal commit-এর জন্য ext4/JBD2 সাধারণত দুটোই ব্যবহার করে: commit block পাঠানোর আগে একটি FLUSH (যাতে data আর journal-এর বাকি block আগে স্থায়ী হয়), আর commit block নিজে FUA-সহ। Linux kernel-এর ভেতরে এই অনুরোধগুলোর চিহ্ন REQ_PREFLUSH আর REQ_FUA. পুরোনো নাম ছিল write barrier — “এই দেয়ালের আগের লেখা দেয়ালের পরের লেখার আগে স্থায়ী হবে” — আর ext4-এর mount বিকল্প barrier (ডিফল্ট চালু) এখনো সেই নাম বহন করে।

এবার দেখুন, এই কোর্সের কোড যে container-এ চলে তার root আর বর্তমান ফোল্ডার কোন file system-এ, কোন বিকল্পে mount করা। একটি জরুরি কথা: /proc/mounts শুধু সেই বিকল্পগুলো দেখায় যা ডিফল্ট থেকে আলাদা — data=ordered ডিফল্ট বলে সেখানে প্রায়ই থাকে না। ext4 নিজের পূর্ণ বিকল্প-তালিকা দেখায় /proc/fs/ext4/<device>/options-এ:

shopt -s nullglob
echo "== 1. root (/) =="
findmnt -n -o FSTYPE /
findmnt -n -o OPTIONS / | tr ',' '\n' | grep -E '^(rw|ro|relatime|fsync=.*)$' | paste -sd' '
echo "== 2. current directory $(pwd) =="
findmnt -n -o FSTYPE,OPTIONS -T .
echo "== 3. ext4 options the kernel really uses (defaults included) =="
files=(/proc/fs/ext4/*/options)
[ ${#files[@]} -gt 0 ] || echo "not visible here"
for f in "${files[@]}"; do
  printf '%s: ' "$(basename "$(dirname "$f")")"
  grep -oE 'data=[a-z]+|nobarrier|barrier|journal_checksum|delalloc|auto_da_alloc|commit=[0-9]+' "$f" | paste -sd' '
done
echo "== 4. jbd2 (the ext4 journal) =="
for f in /proc/fs/jbd2/*/info; do
  echo "$(basename "$(dirname "$f")"): $(grep -m1 'commit time' "$f" | sed 's/^ *//')"
done
echo "== 5. write cache of the virtual disks =="
for f in /sys/block/vd*/queue/write_cache /sys/block/sd*/queue/write_cache /sys/block/nvme*/queue/write_cache; do
  echo "$(echo "$f" | cut -d/ -f4): $(cat "$f")"
done

== 1. root (/) ==
overlay
rw relatime fsync=volatile
== 2. current directory /home/wandbox ==
ext4   rw,relatime
== 3. ext4 options the kernel really uses (defaults included) ==
vda2: delalloc journal_checksum barrier auto_da_alloc commit=5 data=ordered
vdb1: delalloc journal_checksum barrier auto_da_alloc commit=5 data=ordered
== 4. jbd2 (the ext4 journal) ==
vda2-8: 928us average transaction commit time
vdb1-8: 145081us average transaction commit time
== 5. write cache of the virtual disks ==
vda: write back
vdb: write back

৬ · পুরোনো জায়গায় না লেখা — log-structured আর copy-on-write

Journaling-এ প্রতিটি metadata দুবার লেখা হয় — journal-এ আর আসল জায়গায়। যদি প্রতিটি নতুন সংস্করণ সবসময় নতুন খালি জায়গায় লেখা হয়, আর পুরোনোটি অক্ষত থাকে, তাহলে crash-এর সময় পুরোনো সংস্করণটি সবসময় অটুট — শুধু শেষে একটি pointer বদলে “এখন থেকে নতুনটি” বলতে হয়। এই দর্শনের দুটি রূপ।

Log-structured file system (LFS)

১৯৯১ সালে Berkeley-র Mendel Rosenblum আর John Ousterhout SOSP সম্মেলনে Sprite LFS-এর নকশা প্রকাশ করেন। তাঁদের যুক্তি ছিল: RAM বাড়ছে, তাই বেশিরভাগ পড়া cache থেকেই মিটবে; ডিস্কের কাজ হবে মূলত লেখা, আর হার্ড ডিস্ক এলোমেলো ছোট লেখায় ভীষণ ধীর, পরপর বড় লেখায় দ্রুত। তাই LFS সব বদল — data, inode, ফোল্ডার — মেমরিতে জমিয়ে বড় বড় segment-এ (সেই নকশায় ০.৫ থেকে ১ MB) ডিস্কের খালি অংশে পরপর লিখে দেয়, যেন পুরো ডিস্কটাই একটি log.

• Inode কোথায়? Inode-ও প্রতিবার নতুন জায়গায় যায়, তাই তার ঠিকানা স্থির নয়। LFS একটি inode map রাখে (inode নম্বর → এখনকার ঠিকানা), যা নিজেও log-এ লেখা হয়; আর ডিস্কের একটি স্থির জায়গায় checkpoint region সেই map-এর সর্বশেষ টুকরোগুলোর ঠিকানা রাখে, কয়েক সেকেন্ড পরপর হালনাগাদ হয়।
• Crash recovery: শেষ বৈধ checkpoint region পড়া, তারপর তার পরে লেখা segment-গুলো “roll forward” করে যতটা সম্ভব উদ্ধার — fsck-এর মতো পুরো ডিস্ক ঘাঁটতে হয় না।
• দাম — cleaning: পুরোনো সংস্করণগুলো ডিস্কে মৃত হয়ে পড়ে থাকে। একটি cleaner কিছু segment পড়ে, এখনো জীবিত block-গুলো নতুন segment-এ একসাথে লেখে, আর পুরোনো segment খালি করে। কোন segment আগে পরিষ্কার হবে (প্রবন্ধের “cost-benefit” নীতি) কর্মক্ষমতার মূল প্রশ্ন; ডিস্ক প্রায় ভরা থাকলে এর খরচ খুব বাড়ে।

হার্ড ডিস্কে LFS বেশি ছড়ায়নি, কিন্তু flash-এর যুগে তার ধারণা ফিরে এসেছে: SSD-র ভেতরের flash translation layer (পর্ব ৪০) log-structured, আর Samsung-এর F2FS (Linux 3.8) সরাসরি LFS-ধাঁচের — প্র ০৫ দেখুন।

Copy-on-write file system

পর্ব ৩৫-এ fork-এর copy-on-write দেখেছেন — মেমরি-পাতা লিখলে তবেই কপি। File system-এর copy-on-write (COW) একই নামের হলেও নিয়মটি আরও কঠোর: কোনো ব্যবহৃত block কখনো জায়গায় overwrite হয় না। File system-টি একটি গাছ (সাধারণত B-tree-এর রূপ, DSA কোর্সের B-tree পর্ব দেখুন): একেবারে ওপরে একটি root block, নিচে ফোল্ডার আর inode-এর node, পাতায় data block. একটি data block বদলাতে হলে:

1. নতুন data block একটি খালি জায়গায় লেখা হয়।
2. যে node তাকে দেখাত, তার একটি নতুন কপি লেখা হয় নতুন ঠিকানাসহ — সেটিও নতুন জায়গায়।
3. এভাবে root পর্যন্ত পুরো পথের প্রতিটি node-এর নতুন কপি।
4. শেষে ডিস্কের একটি স্থির জায়গার ছোট একটি block — ZFS-এ uberblock, Btrfs-এ superblock — নতুন root-কে দেখাতে হালনাগাদ হয়। এই এক-block লেখাটিই পুরো বদলের commit.

নিচের গাছে root R-এর নিচে দুটি node A আর B, তাদের নিচে চারটি data block L1–L4. ব্যবহারকারী L3 বদলাচ্ছেন। R′, B′, L3′ মানে নতুন কপি; বন্ধনীর সংখ্যা ডিস্কের block নম্বর:

1uberblock -> R ; R -> A, B ; B -> L3, L42write L3' to free block 903write B' (-> L3', L4) to block 914write R' (-> A, B') to block 925FLUSH6write uberblock (txg 101) -> R'7free R, B, L3 unless a snapshot holds them

COW-এর তিনটি উপহার

বাস্তবের COW file system:

• WAFL (Write Anywhere File Layout) — NetApp-এর ফাইল সার্ভারের file system, ১৯৯৪ সালের একটি USENIX প্রবন্ধে (Hitz, Lau ও Malcolm) বর্ণিত; সহজ snapshot-এর পথিকৃৎ।
• ZFS — Sun Microsystems-এ Jeff Bonwick আর Matthew Ahrens-এর দল, ২০০৫ সালে OpenSolaris-এ। File system আর volume manager (RAID, পর্ব ৪৫) একসাথে; প্রতিটি block pointer-এ checksum (ডিফল্ট fletcher4), mirror বা RAID-Z থাকলে খারাপ কপি নিজে সারায়; দ্রুত fsync-এর জন্য আলাদা intent log (ZIL). আজ OpenZFS নামে Linux আর FreeBSD-তে।
• Btrfs — Oracle-এ Chris Mason-এর শুরু (২০০৭), Linux-এ ২০০৯ সালে; COW B-tree, checksum, subvolume ও snapshot; Fedora আর openSUSE-এর ডিফল্ট।
• APFS — Apple-এর file system, ২০১৭ সাল থেকে iOS 10.3 আর macOS High Sierra-তে ডিফল্ট; metadata-র COW, snapshot (Time Machine ব্যবহার করে) আর ফাইলের তাৎক্ষণিক clone. লক্ষ করুন, APFS-এর checksum শুধু metadata-র, ব্যবহারকারীর data-র নয়।

COW-এর দামও আছে: ছোট বদলেও root পর্যন্ত পথ নতুন করে লেখা (write amplification), ক্রমাগত overwrite হওয়া ফাইলের (ডেটাবেস, VM image) block ডিস্কে ছড়িয়ে পড়া (fragmentation), আর ডিস্ক প্রায় ভরা হলে ধীর হয়ে যাওয়া — প্র ০৩-এ বিস্তারিত।

Soft updates আর NTFS — সংক্ষেপে

Soft updates (Greg Ganger আর Yale Patt-এর ধারণা; BSD-র FFS-এ McKusick আর Ganger বাস্তবায়ন করেন, ১৯৯৯ সালে প্রকাশিত) journal ছাড়াই কাজ করে: file system মেমরিতে প্রতিটি block-এর নির্ভরতা মনে রাখে আর লেখার ক্রম এমনভাবে সাজায় যে ডিস্কে কখনো এমন pointer থাকে না যা অপ্রস্তুত কিছুকে দেখায় — যেমন inode-এর আগে data, ফোল্ডার-এন্ট্রির আগে inode. এতে crash-এর পর সবচেয়ে খারাপ ফল শুধু space leak, যা পটভূমিতে fsck দিয়ে ধরা যায়। নকশাটি সুন্দর কিন্তু বাস্তবায়ন অত্যন্ত জটিল; FreeBSD পরে এর সাথে একটি ছোট journal যোগ করে (SU+J).

NTFS-এর $LogFile একটি metadata journal, তবে ext4-এর মতো পুরো block-কপি (physical logging) নয় — এতে লেখা হয় কাজের redo আর undo তথ্য (logical logging), ডেটাবেসের ARIES-ধাঁচের log-এর কাছাকাছি; ব্যবহারকারীর data এতে journal হয় না। Microsoft-এর নতুন ReFS (Windows Server 2012 থেকে) metadata-র জন্য copy-on-write-ধাঁচের পদ্ধতি আর checksum নেয়।

৭ · অ্যাপ্লিকেশনের দায় — fsync, fdatasync আর atomic replace

এ পর্যন্ত যা দেখলেন, সবই file system-এর নিজের কাঠামো বাঁচানোর ব্যবস্থা। ব্যবহারকারীর ডেটা কখন টেকসই হবে, সেটি আলাদা প্রশ্ন। write() ফিরে এলে ডেটা শুধু page cache-এ (dirty page); ext4 সেটি হয়তো কয়েক সেকেন্ড পরে ডিস্কে পাঠাবে। ডেটা যে সত্যিই স্থায়ী হয়েছে — ডেটাবেসের ভাষায় durability — তা নিশ্চিত করতে অ্যাপকে স্পষ্ট করে চাইতে হয় (পর্ব ৪১-এ এর প্রাথমিক পরিচয়):

• fsync(fd): এই ফাইলের সব dirty data আর metadata ডিস্কে লেখা, ডিস্কের cache flush-সহ, শেষ হলে ফেরা। ব্যর্থ হলে -1 আর errno (যেমন EIO).
• fdatasync(fd): data আর শুধু সেই metadata যা পরে ডেটা পড়তে লাগবে (যেমন ফাইলের আকার); শেষ-পরিবর্তনের সময়ের মতো অপ্রয়োজনীয় metadata বাদ — তাই কখনো এক লেখা কম।
• ফোল্ডারের fsync: নতুন ফাইল তৈরি বা rename একটি ফোল্ডারের বদল। Linux-এ নতুন নামটি টেকসই করতে ফোল্ডারটিও খুলে fsync করতে হয়।

Atomic replace প্যাটার্ন

একটি কনফিগ ফাইল বা সেভ-করা গেম হালনাগাদ করতে সবচেয়ে সরল পথ — ফাইল খুলে O_TRUNC দিয়ে খালি করে নতুন লেখা — সবচেয়ে বিপজ্জনক: মাঝপথে crash হলে পুরোনোও নেই, নতুনও অর্ধেক। নিরাপদ পথটি চার ধাপের:

1. নতুন বিষয়বস্তু একই ফোল্ডারের একটি temp ফাইলে লেখা।
2. temp ফাইলের fsync — তার data এখন স্থায়ী।
3. rename(tmp, real) — POSIX নিশ্চয়তা দেয় যে চলমান অন্য প্রসেস কখনো real-কে অনুপস্থিত বা অর্ধেক দেখবে না: হয় পুরোনো ফাইল, নয় নতুন। Journaling file system-এ এই rename একটি metadata transaction, তাই crash-এর পরেও পুরোনো বা নতুন — মাঝামাঝি নয়।
4. ফোল্ডারের fsync — rename নিজে এখন স্থায়ী।

#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

static int save(const char *path, const char *text) {   /* write it, fsync it */
    int fd = open(path, O_WRONLY | O_CREAT | O_TRUNC, 0644);
    if (fd < 0) return -1;
    ssize_t n = write(fd, text, strlen(text));
    int ok = (n == (ssize_t)strlen(text)) && fsync(fd) == 0;
    return (close(fd) == 0 && ok) ? 0 : -1;
}

int main(void) {
    const char *v2 = "balance=7500\nowner=Rahim\n";
    if (save("account.cfg", "balance=5000\nowner=Rahim\n") != 0) return 1;  /* old */
    printf("1. write account.cfg.tmp + fsync      : %s\n",
           save("account.cfg.tmp", v2) == 0 ? "ok" : "FAILED");
    printf("2. rename tmp -> account.cfg (atomic) : %s\n",
           rename("account.cfg.tmp", "account.cfg") == 0 ? "ok" : "FAILED");
    int dir = open(".", O_RDONLY | O_DIRECTORY);         /* make the rename durable */
    printf("3. fsync the directory                : %s\n",
           (dir >= 0 && fsync(dir) == 0) ? "ok" : "FAILED");
    if (dir >= 0) close(dir);
    char buf[64] = {0};
    int fd = open("account.cfg", O_RDONLY);
    ssize_t n = fd >= 0 ? read(fd, buf, sizeof buf - 1) : -1;
    if (fd >= 0) close(fd);
    printf("4. read back %zd bytes, equals new copy: %s\n", n,
           (n > 0 && strcmp(buf, v2) == 0) ? "yes" : "NO");
    printf("5. temp file still there?             : %s\n",
           access("account.cfg.tmp", F_OK) == 0 ? "yes" : "no");
    return 0;
}

1. write account.cfg.tmp + fsync      : ok
2. rename tmp -> account.cfg (atomic) : ok
3. fsync the directory                : ok
4. read back 25 bytes, equals new copy: yes
5. temp file still there?             : no

ভিন্ন OS-এ একই প্যাটার্ন

দুটি বাস্তব শিক্ষা — ২০০৯ আর ২০১৮

২০০৯ — ext4-এর “শূন্য-বাইট ফাইল” বিতর্ক। ext4-এর একটি বড় উন্নতি delayed allocation: write()-এর সময় block বরাদ্দ না করে writeback পর্যন্ত অপেক্ষা, যাতে বড় একটানা জায়গা পাওয়া যায়। ২০০৯ সালের শুরুতে Ubuntu-র পরীক্ষামূলক সংস্করণে ext4 ব্যবহারকারীদের কেউ কেউ জানান, crash-এর পর কনফিগ ফাইল শূন্য বাইটের হয়ে গেছে। যেসব অ্যাপ write tmp → rename করত কিন্তু fsync করত না, তাদের rename-এর metadata কয়েক সেকেন্ডেই commit হতো, অথচ data তখনো বরাদ্দই হয়নি — নতুন নাম একটি খালি ফাইলকে দেখাত। ext3-এর ordered মোডে একই প্যাটার্ন “ঘটনাচক্রে” নিরাপদ ছিল। শেষে দুই দিকেই বদল আসে: ext4-এ একটি heuristic (আজকের auto_da_alloc, উপরের bash আউটপুটে দেখেছেন), আর অনেক অ্যাপে fsync. বিবরণে সূত্রভেদে পার্থক্য আছে; বিতর্কটি প্র ০১-এ। শিক্ষা: আকস্মিক আচরণের ওপর নয়, লিখিত নিশ্চয়তার ওপর ভরসা।

২০১৮ — “fsyncgate”. ২০১৮ সালের মার্চে PostgreSQL-এর মেইলিং লিস্টে Craig Ringer দেখান: PostgreSQL ধরে নিত যে fsync ব্যর্থ হলে পরে আবার fsync করলে kernel লেখাটি আবার চেষ্টা করবে। কিন্তু Linux-এ (আর কয়েকটি অন্য OS-এ) writeback-এর I/O ত্রুটির পর dirty page সাধারণত “পরিষ্কার” হয়ে যেত, ত্রুটির খবর আসত একবারই — দ্বিতীয় fsync সফল ফিরত, অথচ ডেটা ডিস্কে পৌঁছায়নি। PostgreSQL পরের সংশোধনী রিলিজগুলোতে fsync ব্যর্থ হলে সার্ভার থামিয়ে (PANIC) WAL থেকে recovery-র পথ নেয় (প্র ০২)। শিক্ষা: fsync-এর ত্রুটি মানে ডেটা হয়তো চিরতরে গেছে। ডেটাবেসের WAL আর fsync-এর বিস্তারিত DBMS কোর্সের Recovery পর্বে।

৮ · AI-এর যুগে crash consistency

ফাইল নিরাপদে সেভ করার কোড চাইলে AI দ্রুত কোড দেবে, আর সেটি চালালে প্রতিবার “কাজ করবে”। সমস্যা হলো, crash consistency-র বাগ সাধারণ পরীক্ষায় ধরা পড়ে না, ধরা পড়ে লোডশেডিং-এর রাতে। AI-এর পরিচিত ভুলগুলো:

AI-এর কোড মানার আগে — চেকলিস্ট

• চারটি ধাপ (write, fsync file, rename, fsync dir) আছে, আর temp ফাইল একই ফোল্ডারে (ভিন্ন file system-এ rename atomic নয়, এমনকি সম্ভবও নয়)
• প্রতিটি write, fsync, close, rename-এর ত্রুটি সামলানো হয়েছে; আংশিক write-এর ক্ষেত্রেও
• কোন OS আর file system-এর জন্য কোড, তা মিলিয়েছি (man 2 fsync, man 2 rename, Apple বা Microsoft-এর ডকুমেন্টেশন)
• ডেটা কোথায় থাকে দেখেছি — container-এর overlay বা tmpfs-এ fsync-এর অর্থ আলাদা (findmnt -T <path>)
• পরীক্ষার মেশিনে বা VM-এ লেখার মাঝে হঠাৎ বন্ধ করে (VM-এর power off) কয়েকবার ফল যাচাই করেছি; mount বিকল্প বদলানোর আগে কারণসহ প্রমাণ চেয়েছি