অপারেটিং সিস্টেমের ভেতরে — process, scheduling আর file system

১ · এক কম্পিউটার, অনেক দাবিদার — kernel আর দুই mode

এই মুহূর্তে আপনার কম্পিউটারে হয়তো ব্রাউজারে এই পাতা খোলা, পাশে গান বাজছে, পেছনে Windows আপডেট নামাচ্ছে, অ্যান্টিভাইরাস ফাইল দেখছে। অথচ CPU-তে core হয়তো চারটি বা আটটি, আর চলমান প্রোগ্রাম কয়েকশো। সবাই CPU চায়, সবাই RAM চায়, সবাই ডিস্কে লিখতে চায়। কেউ কারও জায়গায় হাত দিলে বা একজন সব সময় দখল করে রাখলে কম্পিউটার অচল হয়ে যেত।

পর্ব ০৬-এ আপনি অপারেটিং সিস্টেমকে দেখেছেন ব্যবহারকারীর চোখে — Start মেনু, ফাইল, সেটিংস। এই পর্বে আমরা ঢুকব পর্দার পেছনে। সেখানে OS-এর আসল পরিচয় একটি বাক্যে:

Kernel space আর user space

OS-এর সব অংশ সমান ক্ষমতার নয়। কেন্দ্রে থাকে kernel — যে সরাসরি CPU, মেমরি আর ডিভাইস নিয়ন্ত্রণ করে। kernel যে মেমরি-এলাকায় থাকে, তাকে বলে kernel space; সেখানে সাধারণ প্রোগ্রামের ঢোকা নিষেধ। আপনার ব্রাউজার, Word, গেম — এমনকি OS-এর অনেক অংশ, যেমন File Explorer বা Settings অ্যাপ — চলে user space-এ।

User mode আর kernel mode — CPU-র ভেতরের তালা

এই ভাগ শুধু নিয়মের খাতায় নয়, CPU-র হার্ডওয়্যারেই বাঁধা। CPU দুই রকম অবস্থায় চলতে পারে। User mode-এ কিছু নির্দেশ (instruction) চালানো নিষেধ — যেমন সরাসরি ডিস্ক কন্ট্রোলারে লেখা, অন্য প্রোগ্রামের মেমরি পড়া, বা টাইমার বন্ধ করা। এমন নির্দেশ চালাতে গেলে CPU নিজেই থেমে OS-কে খবর দেয়, আর OS সাধারণত প্রোগ্রামটি বন্ধ করে দেয়। Kernel mode-এ সব নির্দেশ চলে — শুধু kernel-এর কোড এই অবস্থায় চলে। Intel/AMD CPU-তে এগুলোকে বলে ring 3 আর ring 0; ARM চিপে EL0 আর EL1.

কেন এত কড়াকড়ি? যেকোনো অ্যাপ সরাসরি ডিস্কে লিখতে বা অন্যের মেমরি পড়তে পারলে একটি বাগ-ওয়ালা গেম ফাইল-তালিকা মুছে দিত, আর একটি ক্ষতিকর অ্যাপ ব্যাংকিং অ্যাপের পাসওয়ার্ড পড়ে ফেলত। দুই mode-এর দেয়াল একটি অ্যাপের ভুল সেই অ্যাপের মধ্যেই আটকে রাখে — আধুনিক কম্পিউটারের স্থিরতা আর নিরাপত্তার ভিত্তি এটাই।

২ · System call আর interrupt — নিয়ন্ত্রিত দরজা আর হার্ডওয়্যারের ডাক

অ্যাপ যদি হার্ডওয়্যার ছুঁতেই না পারে, তাহলে Notepad ফাইল সেভ করে কীভাবে? উত্তর: অনুরোধ করে। kernel-এর কাছে কাজ চাওয়ার নির্দিষ্ট, নিয়ন্ত্রিত দরজাকে বলে system call. ব্যাংকের কাউন্টারের মতো ভাবুন — আপনি ভল্টে ঢুকতে পারেন না, কিন্তু কাউন্টারে ফর্ম দিলে কর্মকর্তা আপনার পরিচয় যাচাই করে টাকা এনে দেন।

Windows-এ অ্যাপ সাধারণত সরাসরি system call ডাকে না, ডাকে Win32 API-র ফাংশন (যেমন CreateFileW), আর সেই ফাংশন ভেতরে kernel-এর system call করে। Linux-এ কয়েকশো system call আছে। প্রতিবার system call হলে CPU user mode থেকে kernel mode-এ যায়, kernel কাজ শেষ করে, তারপর আবার user mode-এ ফিরে আসে। নিচে একটি ফাইল খোলার পুরো যাত্রা দেখুন:

Interrupt — হার্ডওয়্যার যেভাবে CPU-র মনোযোগ পায়

CPU যদি বারবার কিবোর্ডকে জিজ্ঞেস করত “কোনো বোতাম চাপা হয়েছে?”, তাহলে তার বেশিরভাগ সময় নষ্ট হতো। এর বদলে হার্ডওয়্যার নিজেই CPU-কে একটি সংকেত পাঠায় — interrupt. ক্লাসে ছাত্র হাত তোলার মতো: শিক্ষক পড়াতে থাকেন, কেউ হাত তুললে এক বাক্য শেষ করে তার কথা শোনেন, তারপর আবার পড়ানো শুরু করেন। CPU-ও তাই করে: হাতের নির্দেশটি শেষ করে, বর্তমান অবস্থা সংরক্ষণ করে, kernel-এর নির্দিষ্ট interrupt handler চালায়, তারপর আগের কাজে ফেরে।

• কিবোর্ড ও মাউস: প্রতিটি চাপ বা নড়াচড়ায় interrupt — তাই টাইপ করা অক্ষর সঙ্গে সঙ্গে পর্দায় আসে।
• ডিস্ক ও নেটওয়ার্ক কার্ড: “ডেটা পড়া শেষ”, “নতুন প্যাকেট এসেছে”।
• টাইমার: সবচেয়ে গুরুত্বপূর্ণ। একটি হার্ডওয়্যার টাইমার নিয়মিত বিরতিতে interrupt দেয়। এতে কোনো প্রোগ্রাম অসীম লুপে আটকে গেলেও kernel নিয়ন্ত্রণ ফিরে পায় আর অন্যকে CPU দিতে পারে (অংশ ৪)।

৩ · Process আর thread — চলমান প্রোগ্রামের জীবন

ডিস্কে রাখা chrome.exe একটি প্রোগ্রাম — নিষ্ক্রিয় একটি ফাইল, রান্নার রেসিপির বইয়ের মতো। আপনি যখন সেটি চালান, OS প্রোগ্রামটি RAM-এ এনে চালু করে — এই চলমান রূপের নাম process. রেসিপি একটি, কিন্তু একই রেসিপি দিয়ে তিনটি চুলায় তিনবার রান্না চলতে পারে — তেমনি একই প্রোগ্রাম থেকে একাধিক process হতে পারে (যেমন দুটি আলাদা Notepad উইন্ডো)।

একটি process-এর ভেতরে কী থাকে

• Code (text): প্রোগ্রামের নির্দেশগুলো — শুধু পড়া যায়।
• Data ও heap: global ভেরিয়েবল আর চলার সময় চাওয়া মেমরি (যেমন খোলা ছবির pixel).
• Stack: কোন ফাংশন কাকে ডেকেছে, local ভেরিয়েবল — কাজ শেষে আপনা-আপনি খালি হয়।
• PCB (Process Control Block): এটি process-এর ভেতরে নয়, kernel-এর কাছে থাকা তার “পরিচয়পত্র” — process ID (PID), বর্তমান অবস্থা, CPU-র register-এর শেষ মান, কোন নির্দেশ পর্যন্ত চলেছে (program counter), কোন মেমরি তার, কোন ফাইল খোলা, অগ্রাধিকার কত। হাসপাতালের রোগীর ফাইলের মতো — ডাক্তার বদলালেও ফাইল দেখে চিকিৎসা ঠিক সেখান থেকে চলে।

Process-এর পাঁচ অবস্থা

জন্ম থেকে মৃত্যু পর্যন্ত একটি process কয়েকটি অবস্থার মধ্যে ঘোরে:

• New: process তৈরি হচ্ছে — PCB বানানো, মেমরি বরাদ্দ।
• Ready: সব প্রস্তুত, শুধু CPU-র অপেক্ষা। এমন process-দের সারিকে বলে ready queue.
• Running: এই মুহূর্তে CPU-তে চলছে। একটি core-এ একসাথে একটিই।
• Waiting (Blocked): কোনো ঘটনার অপেক্ষা — ডিস্ক থেকে ডেটা, ব্যবহারকারীর টাইপ, নেটওয়ার্কের উত্তর। CPU দিলেও এখন কিছু করতে পারত না।
• Terminated: কাজ শেষ বা জোর করে বন্ধ; kernel মেমরি আর PCB ফেরত নেয়।

এবার দেখুন, একটি core-এ দুটি প্রোগ্রাম — A (একটি Excel হিসাব, যে মাঝে ডিস্ক থেকে ফাইল পড়বে) আর B (গান বাজানোর প্রোগ্রাম) — কীভাবে পালা করে চলে:

Thread — একই ঘরে কয়েকজন কারিগর

একটি process-এর ভেতরে কাজের একাধিক স্বাধীন ধারা থাকতে পারে — প্রতিটিকে বলে thread. সব thread একই process-এর কোড, ডেটা আর খোলা ফাইল ভাগ করে নেয়; প্রত্যেকের শুধু নিজের stack আর register-এর মান আলাদা। তাই thread বানানো আর এক thread থেকে আরেক thread-এ যাওয়া process-এর তুলনায় সস্তা — একে “light-weight process” বলা হয়।

উদাহরণ: একটি ওয়েব ব্রাউজার। Chrome শুরু থেকেই (২০০৮) ট্যাবগুলোকে আলাদা process-এ চালানোর নকশা নেয়; আজকের Chrome আর Edge সাধারণত প্রতিটি ওয়েবসাইটকে আলাদা process-এ রাখে — একটি ট্যাব ক্র্যাশ করলে বাকিগুলো বাঁচে, আর এক সাইট আরেক সাইটের মেমরি পড়তে পারে না। আবার প্রতিটি process-এর ভেতরে অনেকগুলো thread — একটি পাতা আঁকে, একটি নেটওয়ার্ক থেকে ডেটা আনে, একটি JavaScript চালায়।

৪ · Multitasking আর CPU scheduling — কে কখন CPU পাবে

একটি core একসাথে একটিই নির্দেশ-ধারা চালায়। তবু আপনি গান শুনতে শুনতে টাইপ করেন, আর মনে হয় সব একসাথে চলছে। রহস্যটা গতিতে। OS প্রত্যেক process-কে ছোট একটি সময়-টুকরো দেয় — time slice বা quantum, সাধারণত কয়েক মিলিসেকেন্ড থেকে কয়েক দশ মিলিসেকেন্ড। টুকরো শেষ হলে টাইমার interrupt আসে, আর kernel পরের জনকে CPU দেয়। সেকেন্ডে শত শত বার এই পালা বদল হয় বলে মানুষের চোখে মনে হয় সবাই একসাথে চলছে — একে বলে multitasking.

Context switch — পালা বদলের খরচ

এক process থেকে আরেক process-এ যেতে kernel-কে তিনটি কাজ করতে হয়: চলমান process-এর register আর program counter তার PCB-তে লিখে রাখা, পরের process-এর PCB থেকে সেগুলো CPU-তে ফিরিয়ে আনা, আর মেমরির মানচিত্র বদলানো। এর নাম context switch. এতে সাধারণত কয়েক মাইক্রোসেকেন্ড লাগে, আর এই সময়টায় কোনো ব্যবহারকারীর কাজ হয় না — শুধু হিসাবরক্ষণ। এজন্য time slice খুব ছোট করলে CPU-র বড় অংশ পালা বদলেই নষ্ট হয়, আর খুব বড় করলে কম্পিউটার “আটকে আটকে” চলে মনে হয়।

Scheduling-এর হিসাবের ভাষা

Ready queue-তে কয়েকটি process দাঁড়িয়ে — scheduler কাকে আগে দেবে? সেটা ঠিক হয় scheduling algorithm দিয়ে। তুলনার জন্য কয়েকটি মাপ লাগে:

• Burst time: একটি process-এর মোট কতক্ষণ CPU লাগবে।
• Turnaround time: আসা থেকে শেষ হওয়া পর্যন্ত মোট সময় = শেষ হওয়ার সময় − আসার সময়।
• Waiting time: ready queue-তে মোট অপেক্ষা = turnaround time − burst time.
• Response time: আসা থেকে প্রথমবার CPU পাওয়া পর্যন্ত সময় — ব্যবহারকারীর কাছে “কম্পিউটার কত দ্রুত সাড়া দেয়” তার মাপ।

একটি উদাহরণ ধরুন, যা পুরো অংশে চলবে। চারটি process, সবাই সময় ০-তে একসাথে এসেছে, সারিতে P1, P2, P3, P4 ক্রমে দাঁড়িয়ে (সময় যেকোনো এককে, ধরুন মিলিসেকেন্ড):

চারটি পরিচিত algorithm

• FCFS (First Come, First Served): যে আগে এসেছে সে আগে — ব্যাংকের লাইনের মতো। সহজ, কিন্তু সামনে একটি লম্বা কাজ থাকলে পেছনের ছোট কাজগুলো অযথা বসে থাকে (একে বলে convoy effect).
• SJF (Shortest Job First): যার burst সবচেয়ে ছোট সে আগে। সবাই একসাথে এলে গড় waiting time সবচেয়ে কম হয় — গাণিতিকভাবে প্রমাণিত। সমস্যা: ভবিষ্যতে কোন কাজ কতক্ষণ লাগবে, OS আগে থেকে জানে না; আগের আচরণ দেখে অনুমান করতে হয়। এর preemptive রূপকে বলে SRTF (Shortest Remaining Time First).
• Round Robin (RR): সবাই পালা করে একটি করে quantum পায়; শেষ না হলে লাইনের পেছনে গিয়ে দাঁড়ায়। কেউ বেশিক্ষণ বঞ্চিত থাকে না — time-sharing কম্পিউটারের মূল নীতি।
• Priority: সবচেয়ে জরুরি জন আগে। হাসপাতালের জরুরি বিভাগের মতো — সর্দি-কাশির রোগী আগে এলেও দুর্ঘটনার রোগী আগে চিকিৎসা পান।

FCFS-এ সারির ক্রমেই চলে: P1 ০–৬, P2 ৬–৯, P3 ৯–১০, P4 ১০–১৪. waiting time যথাক্রমে ০, ৬, ৯, ১০ — গড় ২৫ ÷ ৪ = ৬.২৫. SJF-এ ছোট থেকে বড়: P3 ০–১, P2 ১–৪, P4 ৪–৮, P1 ৮–১৪ — waiting ০, ১, ৪, ৮, গড় ১৩ ÷ ৪ = ৩.২৫. এবার Round Robin, quantum ২ — ধাপে ধাপে Gantt chart ভরাট করুন:

FCFS      |        P1       |   P2   |P3|     P4    |
          0                 6        9 10          14
SJF       |P3|   P2   |     P4    |        P1       |
          0  1        4           8                14
RR q=2    |  P1 |  P2 |P3|  P4 |  P1 |P2|  P4 |  P1 |
          0     2     4  5     7     9 10    12    14
Priority  |   P2   |     P4    |        P1       |P3|
          0        3           7                13 14

অবাক হওয়ার মতো ফল: এই সেটে Round Robin-এর গড় waiting time সবচেয়ে বেশি! তাহলে Windows, Linux কেন RR-ঘরানার নীতি ব্যবহার করে? কারণ শেষ কলাম — response time. RR-এ প্রত্যেকে খুব দ্রুত প্রথম সুযোগ পায় (গড় ২.৭৫), তাই আপনি কোনো বোতাম চাপলে কম্পিউটার সাথে সাথে সাড়া দেয়। ডেস্কটপ আর ফোনে ব্যবহারকারীর কাছে এটাই সবচেয়ে জরুরি। কোনো একটি algorithm সব মাপে সেরা নয় — প্রতিটি একটি trade-off.

Starvation — অনন্ত অপেক্ষা

Priority scheduling-এ P3-এর দিকে তাকান: তার কাজ মাত্র ১ একক, তবু সে অপেক্ষা করেছে ১৩ একক, কারণ তার priority সবচেয়ে কম। এখন ভাবুন, জরুরি process নিয়মিত আসতেই থাকে — তাহলে P3 হয়তো কখনোই CPU পাবে না। একে বলে starvation. প্রচলিত সমাধান aging: কেউ যত বেশি অপেক্ষা করে, তার priority ধীরে ধীরে তত বাড়ানো হয় — বয়স্ক যাত্রীকে লাইনে এগিয়ে দেওয়ার মতো। SJF-এও একই বিপদ আছে: ছোট কাজ আসতে থাকলে বড় কাজ বঞ্চিত থাকে।

নিজে চালিয়ে দেখুন — scheduling সিমুলেটর

নিচের কোড একই চারটি process-এ FCFS, SJF আর Round Robin চালিয়ে টেক্সট Gantt chart আর গড় সময় লিখে দেয়। লক্ষ করুন, তিনটি algorithm-এর জন্য একটিই ফাংশন: FCFS আর SJF আসলে “quantum অসীম” Round Robin — শুধু সারির ক্রম আলাদা।

const procs = [['P1', 6], ['P2', 3], ['P3', 1], ['P4', 4]]; // নাম, burst; সবাই সময় 0-তে
function run(title, order, q) {            // order: সারির ক্রম, q: quantum
  const queue = order.map(([n, b]) => ({ n, b, left: b }));
  let t = 0, bar = '', wait = 0, tat = 0;
  while (queue.length) {
    const p = queue.shift();                // সারির সামনের জন CPU পায়
    const slice = Math.min(q, p.left);      // এবার কতক্ষণ চলবে
    bar += `|${p.n} ${t}-${t + slice}`;
    t += slice;
    p.left -= slice;
    if (p.left > 0) queue.push(p);          // শেষ হয়নি: লাইনের পেছনে
    else { tat += t; wait += t - p.b; }     // শেষ: turnaround = t, waiting = t - burst
  }
  const k = order.length;
  console.log(`${title}\n  ${bar}|\n  avg waiting = ${wait / k}, avg turnaround = ${tat / k}`);
}
run('FCFS', procs, Infinity);
run('SJF', [...procs].sort((a, b) => a[1] - b[1]), Infinity);
run('Round Robin (q=2)', procs, 2);

৫ · Process-দের সহযোগিতা আর বিপদ — IPC, synchronization আর deadlock

Process-রা একা একা কাজ করে না। আপনি ব্রাউজার থেকে কিছু কপি করে Word-এ পেস্ট করেন; একটি প্রোগ্রামের আউটপুট আরেকটির ইনপুট হয়। process-দের মধ্যে ডেটা আদান-প্রদানকে বলে IPC (Inter-Process Communication). প্রধান উপায়গুলো: shared memory (kernel দুজনকে একটি সাধারণ মেমরি-এলাকা দেয়), message passing (kernel-এর মাধ্যমে চিঠি পাঠানোর মতো), pipe (একজনের আউটপুট সরাসরি আরেকজনের ইনপুটে — পর্ব ২৯-এ কমান্ড লাইনে | চিহ্নে দেখবেন), আর নেটওয়ার্ক socket.

Race condition আর lock

একই ডেটা দুজন একসাথে বদলাতে গেলে বিপদ। ধরুন একটি bKash-ধরনের অ্যাকাউন্টে ১,০০০ টাকা আছে, আর দুটি thread প্রায় একই মুহূর্তে ৫০০ করে জমা দিচ্ছে। প্রত্যেকে আগে ব্যালান্স পড়ে (১,০০০), তারপর ৫০০ যোগ করে লেখে (১,৫০০)। দুজনেই ১,০০০ পড়ে থাকলে শেষ ফল ২,০০০ না হয়ে ১,৫০০ — ৫০০ টাকা হাওয়া! ফল নির্ভর করছে কে কখন চলল তার ওপর — একে বলে race condition. সমাধান: যে অংশে সাধারণ ডেটা বদলায় (critical section), সেখানে একসাথে একজনই ঢুকবে। এজন্য ব্যবহার হয় lock বা mutex — বাথরুমের ছিটকিনির মতো, একজন ভেতরে থাকলে বাকিরা বাইরে অপেক্ষা করে। আরও সাধারণ একটি হাতিয়ার semaphore — একটি গণক, যা বলে দেয় একসাথে সর্বোচ্চ কতজন ঢুকতে পারবে (পার্কিং লটের খালি জায়গার বোর্ডের মতো)।

Deadlock — কেউ এগোতে পারে না

lock সমস্যা মেটায়, কিন্তু নতুন একটি বিপদ আনে। পুরান ঢাকার একটি সরু গলিতে দুই দিক থেকে দুটি রিকশা ঢুকে মুখোমুখি দাঁড়িয়েছে। কেউ পেছাতে রাজি নয়, তাই কেউই এগোতে পারছে না — চিরকালের জন্য আটকে। একই ঘটনা process-দের মধ্যে হলে তাকে বলে deadlock. নিচে দুটি lock দিয়ে কীভাবে ঘটে আর কীভাবে এড়ানো যায় দেখুন:

১৯৭১ সালে E. G. Coffman ও তাঁর সহকর্মীরা দেখান, deadlock হতে হলে চারটি শর্ত একসাথে সত্য হতে হয় (Coffman conditions):

1. Mutual exclusion: সম্পদটি একসাথে একজনই ব্যবহার করতে পারে।
2. Hold and wait: একজন কিছু ধরে রেখে আরও কিছুর জন্য অপেক্ষা করে।
3. No preemption: কারও হাত থেকে জোর করে সম্পদ কেড়ে নেওয়া যায় না।
4. Circular wait: অপেক্ষার একটি চক্র — P1 অপেক্ষা করে P2-এর, P2 অপেক্ষা করে P1-এর।

চারটির যেকোনো একটি ভাঙলেই deadlock অসম্ভব। ওপরের stepper-এ lock-এর নির্দিষ্ট ক্রম “circular wait” ভেঙেছে।

৬ · মেমরি আর file system — block থেকে ফাইল

মেমরি ব্যবস্থাপনা — এক নজরে

প্রত্যেক process-কে OS নিজস্ব একটি “কাল্পনিক” ঠিকানা-জগৎ দেয় — virtual memory. process ভাবে ঠিকানা ০ থেকে শুরু করে বিশাল একটি মেমরি তার একার; আসলে OS আর CPU-র একটি অংশ (MMU) মিলে প্রতিটি ঠিকানা RAM-এর আসল জায়গায় অনুবাদ করে, page নামের ছোট টুকরো ধরে। এতে দুটি বড় লাভ: এক process আরেক process-এর মেমরি দেখতেই পায় না (সুরক্ষা), আর RAM ভরে গেলে কম ব্যবহৃত page স্টোরেজে সরিয়ে রাখা যায় (paging/swapping). page, page table আর TLB-র পুরো গল্প পর্ব ২৫-এ পাবেন; এখানে শুধু মনে রাখুন — মেমরিও CPU-র মতোই OS-এর ভাগ করে দেওয়া সম্পদ।

File system — ডিস্কের কাঁচা block থেকে ফাইল-ফোল্ডার

SSD বা HDD নিজে “ফাইল” চেনে না। সে চেনে শুধু নম্বর দেওয়া সমান মাপের টুকরো — block (সাধারণত ৪ KB). “block ৮১২৩৪ পড়ো”, “block ৫০২-এ লেখো” — ব্যস। এই কাঁচা block-এর সারিকে নাম, ফোল্ডার, তারিখ আর অনুমতিওয়ালা ফাইলের জগতে রূপ দেয় file system. একটি বিশাল গুদামের কথা ভাবুন, যেখানে হাজার হাজার নম্বর দেওয়া তাক আছে। file system হলো গুদামের খাতা — কোন মালিকের কোন মাল কোন কোন তাকে আছে।

file system তিন রকম তথ্য রাখে:

• ডেটা block: ফাইলের আসল বিষয়বস্তু — লেখা, ছবির pixel, গানের নমুনা।
• Metadata: ফাইল সম্পর্কে তথ্য — আকার, মালিক, অনুমতি, তৈরি ও বদলের সময়, আর কোন কোন block-এ ডেটা আছে। Linux-এর ext4-এ প্রতিটি ফাইলের metadata থাকে একটি inode-এ; NTFS-এ একই কাজ করে MFT (Master File Table)-এর একটি এন্ট্রি।
• Directory: একটি ফোল্ডার আসলে একটি বিশেষ ফাইল, যার ভেতরে শুধু একটি তালিকা: “এই নাম → এই inode নম্বর”। Unix-ধরনের সিস্টেমে ফাইলের নাম inode-এ নয়, এই তালিকাতেই থাকে। তাই একই ড্রাইভের ভেতরে ফাইল সরানো (move) প্রায় তাৎক্ষণিক — শুধু তালিকার একটি লাইন বদলায়, ডেটা নড়ে না।

Fragmentation আর journaling

ফাইল বারবার তৈরি, বড় আর মোছা হতে হতে একটি ফাইলের block ডিস্কের নানা জায়গায় ছড়িয়ে যায় — একে বলে fragmentation. HDD-তে এতে পড়ার মাথাকে বারবার লাফাতে হয়, তাই কম্পিউটার ধীর হয়; এর প্রতিকার defragmentation (পর্ব ০৮-এ দেখেছেন)। SSD-তে যেকোনো block পড়তে সমান সময় লাগে, তাই সেখানে এটি প্রায় সমস্যাই নয়।

এবার ভাবুন, ফাইল সেভ হওয়ার মাঝপথে লোডশেডিং। ডেটা হয়তো অর্ধেক লেখা হয়েছে, আর metadata হয়তো বলছে ফাইলটি পুরো — file system-এর খাতা আর তাকের মাল মিলছে না। আধুনিক file system ব্যবহার করে journaling: বড় পরিবর্তনের আগে একটি আলাদা খাতায় (journal) লিখে রাখে “এই কাজটি করতে যাচ্ছি”, কাজ শেষে লেখে “করা হয়েছে”। মাঝপথে বিদ্যুৎ গেলে চালু হওয়ার পর journal দেখে অসমাপ্ত কাজ শেষ করে বা বাতিল করে — দোকানের খাতায় আগে লিখে তারপর মাল দেওয়ার মতো। FAT32 আর exFAT-এ সাধারণত journaling নেই, এজন্য পেনড্রাইভ খোলার আগে “Safely Remove” বা “Eject” করা জরুরি।

৭ · অনুমতি, driver আর OS-এর জানালা

Permission — কে কী করতে পারবে

একটি কম্পিউটারে অনেক ব্যবহারকারী থাকতে পারেন, আর OS-এর নিজের ফাইলও আছে। তাই প্রতিটি ফাইলের সাথে metadata-য় লেখা থাকে কে কী করতে পারবে — file permission. Unix আর Linux-এ তিন রকম অনুমতি: r (read — পড়া), w (write — বদলানো), x (execute — প্রোগ্রাম হিসেবে চালানো; ফোল্ডারের ক্ষেত্রে ভেতরে ঢোকা)। আর তিন দল মানুষ: owner (মালিক), group (একই দলের সদস্য), others (বাকি সবাই)।

-rwxr-x---  1 rahim  staff  report.sh
 ───┬──┬──┬
    │  │  └─ others: ---  কিছুই না            → 0
    │  └──── group : r-x  পড়া ও চালানো         → 4+0+1 = 5
    └─────── owner : rwx  পড়া, লেখা, চালানো   → 4+2+1 = 7      সংখ্যায়: 750

r = ৪, w = ২, x = ১ ধরে যোগ করলে প্রতিটি দলের অনুমতি একটি অঙ্কে লেখা যায়, তাই chmod 750 report.sh কমান্ড ঠিক ওপরের অনুমতি বসায় (কমান্ড লাইনের সাথে পরিচয় হবে পর্ব ২৯-এ)। Windows-এ ধারণাটি আরও বিস্তারিত — ACL (Access Control List): প্রতিটি ফাইলের সাথে একটি তালিকা, যেখানে আলাদা আলাদা ব্যবহারকারী বা দলের জন্য Read, Write, Modify, Full control ইত্যাদি দেওয়া বা নিষেধ করা থাকে। ফাইলে ডান-ক্লিক → Properties → Security ট্যাবে এটি দেখা যায়। সব অনুমতির ঊর্ধ্বে থাকেন administrator (Linux-এ root) — এজন্য প্রতিদিনের কাজ সাধারণ অ্যাকাউন্টে করাই নিরাপদ।

Device driver — kernel-এর দোভাষী

পর্ব ০৫-এ দেখেছেন, driver হলো হার্ডওয়্যার আর OS-এর মাঝের দোভাষী। ভেতর থেকে দেখলে, kernel সব প্রিন্টারের সাথে একই ভাষায় কথা বলে — “এই পাতা ছাপাও”। প্রতিটি কোম্পানির প্রিন্টারের নিজস্ব কমান্ড অনুবাদ করে তার driver. বেশিরভাগ driver kernel mode-এ চলে, তাই একটি খারাপ driver পুরো সিস্টেম ফেলে দিতে পারে — ২০২৪ সালের জুলাইয়ে একটি নিরাপত্তা-সফটওয়্যারের ত্রুটিপূর্ণ আপডেট kernel-স্তরে চলায় বিশ্বজুড়ে লাখ লাখ Windows কম্পিউটার নীল পর্দায় আটকে গিয়েছিল। চালু হওয়ার সময় driver কীভাবে লোড হয়, তা পরের পর্বে (পর্ব ২৭) দেখবেন।

Task Manager আর top — OS-এর ভেতরে উঁকি

এই পর্বের প্রায় সবকিছু আপনি নিজের চোখে দেখতে পারেন। Windows-এ Ctrl+Shift+Esc চেপে Task Manager খুলুন:

• Processes ট্যাব: প্রতিটি process আর তার CPU, মেমরি, ডিস্ক, নেটওয়ার্ক ব্যবহার।
• Performance ট্যাব: CPU অংশে নিচে লেখা থাকে মোট Processes, Threads আর Handles — সাধারণত কয়েকশো process আর কয়েক হাজার thread, অথচ core মাত্র কয়েকটি! scheduling-এর কাজ কত বড়, এই সংখ্যাতেই বোঝা যায়।
• Details ট্যাব: প্রতিটি process-এর PID — PCB-র সেই পরিচয় নম্বর। ডান-ক্লিক → Set priority দিয়ে priority-ও বদলানো যায় (সাবধানে)।

Linux বা Mac-এর টার্মিনালে top (বা আরও রঙিন htop) লিখলে একই তথ্য — প্রতিটি process-এর PID, অবস্থা (R = running, S = sleeping/waiting), CPU% আর মেমরি। macOS-এ গ্রাফিক্যাল রূপটির নাম Activity Monitor.

৮ · OS-এর প্রকারভেদ, virtualization আর container

সব কম্পিউটারের কাজ এক নয়, তাই OS-ও এক রকম নয়। ইতিহাস আর ব্যবহার মিলিয়ে প্রধান ধরনগুলো:

Real-time মানে “খুব দ্রুত” নয় — মানে “নিশ্চিত সময়ের মধ্যে”। গাড়ির airbag-এর সেন্সর ধাক্কা টের পেলে কয়েক দশ মিলিসেকেন্ডের মধ্যে ব্যাগ ফোলাতে হয়; গড়ে দ্রুত হলে চলবে না, প্রতিবারই সময়মতো হতে হবে। তাই এমন যন্ত্রের সফটওয়্যার কঠোর real-time নিয়মে নকশা করা হয়, আর priority scheduling সেখানে কেন্দ্রীয় হাতিয়ার।

Virtualization — এক কম্পিউটারে কয়েকটি কম্পিউটার

OS যেমন একটি CPU-কে অনেক process-এর মধ্যে ভাগ করে, তেমনি আরেক স্তর নিচে একটি পুরো কম্পিউটারকে কয়েকটি “কাল্পনিক কম্পিউটারে” ভাগ করা যায়। প্রতিটিকে বলে virtual machine (VM), আর ভাগ করে দেওয়া সফটওয়্যারটির নাম hypervisor. Windows ল্যাপটপে VirtualBox বা Hyper-V দিয়ে একটি Linux VM চালালে সেই Linux ভাবে তার নিজের CPU, RAM আর ডিস্ক আছে — আসলে সবই hypervisor-এর দেওয়া।

Container — হালকা খাঁচা

প্রতিটি VM-এ একটি পুরো OS চলে — কয়েক GB মেমরি আর চালু হতে অনেক সময়। অনেক সময় শুধু একটি অ্যাপকে আলাদা রাখাই যথেষ্ট। Container (সবচেয়ে পরিচিত টুল Docker, ২০১৩) ঠিক তা-ই করে: সব container একই host OS-এর kernel ভাগ করে, কিন্তু kernel প্রত্যেককে আলাদা ফাইল, আলাদা process-তালিকা আর আলাদা নেটওয়ার্ক দেখায়। ফলে container চালু হয় সেকেন্ডে, আর একটি সার্ভারে শত শত চলতে পারে।

৯ · AI-এর যুগে — ব্যাখ্যা নিন, হিসাব নিজে মেলান

OS-এর ধারণা বোঝাতে AI চ্যাটবট সত্যিই ভালো: “context switch সহজ উপমায় বোঝাও”, “thread আর process-এর পার্থক্য টেবিলে দাও” — এমন প্রশ্নে সাধারণত পরিষ্কার উত্তর আসে। কিন্তু scheduling-এর অঙ্কে AI প্রায়ই ভুল করে, আর ভুলটা দেখায় খুব আত্মবিশ্বাসী। কারণ AI ধাপে ধাপে সারি চালিয়ে দেখে না, পরের শব্দ অনুমান করে লেখে; লম্বা Gantt chart-এ একটি ভুল পালা পরের সব সংখ্যা বদলে দেয়।

AI-এর উত্তর হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Gantt chart নিজে খাতায় আবার এঁকেছি, প্রতিটি পালার পর queue লিখে
• Gantt chart-এর মোট দৈর্ঘ্য সব burst-এর যোগফলের (আর অলস সময়ের) সমান
• প্রতিটি waiting time শূন্য বা ধনাত্মক, আর waiting + burst = turnaround মিলেছে
• গড় করার সময় process-এর সংখ্যা দিয়েই ভাগ করেছি
• সন্দেহ থাকলে ওপরের JavaScript সিমুলেটরে একই সংখ্যা বসিয়ে মিলিয়েছি (সবাই সময় ০-তে এলে)
• OS-এর ইতিহাস বা কোনো নির্দিষ্ট OS-এর আচরণ নিয়ে AI-এর দাবি অফিসিয়াল ডকুমেন্টেশন বা নির্ভরযোগ্য বইয়ে মিলিয়েছি