Windows I/O-এর গভীরতা (৫ম কিস্তি) — NTFS-এর অভ্যন্তরীণ কাঠামো: MFT থেকে বোঝা ফাইল সিস্টেম

এ পর্যন্ত চার কিস্তিতে I/O অনুরোধ কীভাবে বয়ে (১ম〜৩য় কিস্তি), ক্যাশ কীভাবে গ্রহণ করে (৪র্থ কিস্তি) দেখেছি। অনুরোধ শেষে ফাইল সিস্টেম-এ পৌঁছায়। এবার তার প্রতিনিধি, NTFS-এর পালা।

দৃষ্টি বদলায়। এতদিন «অনুরোধের প্রবাহ» গতিশীল কথা ছিল। এবার ডিস্কে ডেটা কীভাবে রাখা স্থির কাঠামোর কথা। ডাউনলোড ফাইলে লাগানো অদেখা «Zone.Identifier»-এর সত্তা। ছোট ফাইল দশ হাজার কপি একই মোট আকারের এক ফাইলের চেয়ে অনেক ধীর কেন। «NTFS জার্নালিং তাই নিশ্চিন্ত» কতদূর সত্য — সব এই কাঠামো থেকে ব্যাখ্যা যায়।

ধারাবাহিক «Windows I/O-এর গভীরতা»-এর ৫ম কিস্তি।

এই কিস্তি পড়ার পূর্বজ্ঞান: ১ম কিস্তির IRP ও ডিভাইস স্ট্যাকের মূল ধরলে পড়া সহজ। তবে একা পড়লেও অসুবিধা না হয় বলে দেহে আসা আগের কিস্তির পরিভাষা আগে সংজ্ঞায়িত করি।

সারণি ১: এই কিস্তিতে ধরা আগের কিস্তির পরিভাষা

আর একটা, ১ম কিস্তিতে সামলানো cleanup (শেষ হ্যান্ডেল বন্ধ) ও close (কার্নেলের ভিতর সব রেফারেন্স মিলিয়ে যাওয়া) দুই ধাপ ৪ অধ্যায়ের ফাইল মুছার ব্যাখ্যায় ব্যবহার করি।

1. আগে উপসংহার

• NTFS-এর কেন্দ্র MFT (মাস্টার ফাইল টেবিল)। সব ফাইল MFT-এর রেকর্ড হিসেবে খাতায় সামলানো, ফাইল সম্পর্কিত সব তথ্য «MFT এন্ট্রির ভিতরে» বা «এন্ট্রি নির্দেশ করা MFT-এর বাইরের জায়গায়» (২ অধ্যায়)।¹
• ফাইলের সত্তা «অ্যাট্রিবিউটের সমষ্টি»। ছোট ফাইল ডেটা সত্তাসহ MFT রেকর্ডের ভিতরে ধরে (রেসিডেন্ট), বড় ফাইল ক্লাস্টার সারির রেফারেন্সই রাখে (নন-রেসিডেন্ট)। ছোট ফাইল প্রচুর প্রক্রিয়ার ধীরতা এখান থেকে ব্যাখ্যা যায় (২ অধ্যায়)।¹
• ডেটা একাধিক রাখা যায় (একাধিক ডেটা স্ট্রিম)। সাধারণ ডেটা «নামহীন স্ট্রিম», file.txt:নাম দিয়ে অতিরিক্ত স্ট্রিম রাখা যায়। Zone.Identifier (Mark of the Web)-এর সত্তা (৩ অধ্যায়)।²
• নামও অ্যাট্রিবিউট। একই রেকর্ডে একাধিক নাম লাগানোটা হার্ড লিঙ্ক। 8.3 সংক্ষিপ্ত নামও «আর একটা নাম» হিসেবে পাশাপাশি (৪ অধ্যায়)।³⁴
• রিপার্স পয়েন্ট «খুললে অন্য জায়গা»-র সরকারি ব্যবস্থা। সিম্বলিক লিঙ্ক·জাংশন·OneDrive ফাইল অন ডিমান্ড সব এই ট্যাগসহ ডেটার প্রয়োগ (৫ অধ্যায়)।⁵⁶
• জার্নাল দুটো। $LogFile মেটাডেটা সামঞ্জস্য পুনরুদ্ধার-এর জন্য (না ভাঙার অগ্রবর্তী লগ), USN জার্নাল বদলের ইতিহাস রেকর্ড-এর জন্য (কী বদলেছে তার খাতা)। ভূমিকা একেবারে আলাদা (৬ অধ্যায়)।⁷⁸
• «আকার» আর «ডিস্কে আকার» আলাদা জিনিস। স্পার্স ফাইল ও কম্প্রেশন ফারাক জন্মায়। ২য় কিস্তিতে দেখা «কম্প্রেসড ফাইল অ্যাসিঙ্ক্রোনাস হয় না»-র পটভূমিও এখানে (৭ অধ্যায়)।⁹¹⁰

চিত্রে, টানা রেখা সবসময় সত্য এমন সম্পর্ককে এবং ভাঙা রেখা শর্তসাপেক্ষ সম্পর্ককে নির্দেশ করে (শর্তগুলো বিস্তারিত পাতায় প্রতিটি সম্পর্কের ব্যাখ্যায় আছে)। সম্পর্কের সম্পূর্ণ তালিকা (মোট 35, প্রমাণ ও নিশ্চয়তার মাত্রাসহ) এবং প্রধান ধারণাগুলোর সংজ্ঞা জ্ঞান মানচিত্রের বিস্তারিত পাতায় সংগ্রহ করা আছে (জাপানি ভাষায়)। তথ্য: JSON-LD / Turtle

2. সবই MFT-এর রেকর্ড

2.1. ভলিউমের খাতা

NTFS ভলিউম ফরম্যাট করলে MFT (master file table) ও $ দিয়ে শুরু মেটাডেটা ফাইলের ধারা তৈরি হয়। MFT-তে ভলিউমের সব ফাইলের জন্য অন্তত একটা এন্ট্রি আছে, MFT নিজের এন্ট্রিও আছে।¹

flowchart TB
    subgraph VOL["NTFS ভলিউম"]
        MFT["$MFT ── মাস্টার ফাইল টেবিল<br/>সব ফাইলের রেকর্ডের খাতা (নিজেও আছে)"]
        LOG["$LogFile ── মেটাডেটা অপারেশনের<br/>লেনদেন লগ (৬ অধ্যায়)"]
        BITMAP["$Bitmap ── ক্লাস্টার ব্যবহারের অবস্থা"]
        OTH["$Boot / $Secure / $UpCase ইত্যাদি<br/>অন্য মেটাডেটা ফাইল"]
        DATA["ব্যবহারকারী ডেটা জায়গা<br/>(নন-রেসিডেন্ট ডেটার জায়গা)"]
    end
    MFT -->|"রেকর্ড অবস্থান নির্দেশ করে"| DATA

চিত্র ১: NTFS ভলিউমের কাঠামো। «ফাইল সিস্টেম নিজের ব্যবস্থাপনা তথ্যও ফাইল হিসেবে রাখে» NTFS-এর নকশা

ফাইল সম্পর্কিত তথ্য — আকার, টাইমস্ট্যাম্প, অ্যাক্সেস অনুমতি, আর ডেটার ভিতর পর্যন্ত — MFT এন্ট্রির ভিতরে থাকে, অথবা MFT এন্ট্রি যে অবস্থান বর্ণনা করে সেই MFT-এর বাইরের জায়গায় থাকে।¹ ফাইল মুছলে এন্ট্রি «ফাঁকা» চিহ্নিত হয়ে পুনর্ব্যবহার হয়, কিন্তু MFT নিজে ছোট হয় না। আর MFT ধারাবাহিক রাখতে MFT জোন নামের জায়গা সংরক্ষিত, ভলিউম ভরতে শুরু করলে MFT-এর খণ্ডীকরণ শুরু হয় — এই আয়ুর কথাও সরকারি নথিতে আছে।¹

2.2. ফাইল = অ্যাট্রিবিউটের সমষ্টি, রেসিডেন্ট ও নন-রেসিডেন্ট

ফাইল রেকর্ডের ভিতর অ্যাট্রিবিউটের তালিকা। মানক তথ্য (টাইমস্ট্যাম্প ইত্যাদি), ফাইল নাম, নিরাপত্তা, আর ডেটা। এখানে জরুরি শাখা আছে।

flowchart TB
    subgraph REC["MFT ফাইল রেকর্ড (এক ফাইলের খাতা)"]
        STD["মানক তথ্য অ্যাট্রিবিউট<br/>টাইমস্ট্যাম্প·অ্যাট্রিবিউট ফ্ল্যাগ"]
        FN["ফাইল নাম অ্যাট্রিবিউট<br/>(একাধিক রাখা যায় ── ৪ অধ্যায়)"]
        DATA["ডেটা অ্যাট্রিবিউট"]
    end
    Q{"ডেটা ছোট কি"}
    RES["রেসিডেন্ট (resident)<br/>ডেটা সত্তা রেকর্ডের ভিতরে ধরে<br/>পড়া শুধু MFT অ্যাক্সেসে শেষ"]
    NONRES["নন-রেসিডেন্ট (non-resident)<br/>রেকর্ডে «ক্লাস্টার সারির রেফারেন্স» মাত্র<br/>সত্যি ডেটা ব্যবহারকারী ডেটা জায়গায়"]
    DATA --> Q
    Q -->|"কয়েকশ বাইট পর্যন্ত"| RES
    Q -->|"তার বেশি"| NONRES

চিত্র ২: ফাইল রেকর্ড অ্যাট্রিবিউটের সমষ্টি। ডেটা ছোট হলে রেকর্ডের ভিতরে «রেসিডেন্ট»

একই রেকর্ডের ভিতর রেসিডেন্ট ও নন-রেসিডেন্টে কীভাবে বদলায় পাশাপাশি দেখলে সহজ।

flowchart LR
    subgraph RES2["রেসিডেন্ট (resident) ── ছোট ফাইল"]
        RA["MFT ফাইল রেকর্ড (স্থির দৈর্ঘ্য)<br/>মানক তথ্য / ফাইল নাম / নিরাপত্তা<br/>─────────────<br/>ডেটা অ্যাট্রিবিউট = ভিতর নিজে<br/>«সেটিং মান=1» এখানে সরাসরি"]
        RB["ডিস্কে আলাদা জায়গা নেই<br/>পড়া শুধু MFT অ্যাক্সেসে শেষ"]
        RA --> RB
    end
    subgraph NON2["নন-রেসিডেন্ট (non-resident) ── বড় ফাইল"]
        NA["MFT ফাইল রেকর্ড (স্থির দৈর্ঘ্য)<br/>মানক তথ্য / ফাইল নাম / নিরাপত্তা<br/>─────────────<br/>ডেটা অ্যাট্রিবিউট = ডেটা রানের সারণি<br/>«কোথা থেকে কত ক্লাস্টার» সারি"]
        NB["ব্যবহারকারী ডেটা জায়গা<br/>রান ১: ধারাবাহিক ক্লাস্টার"]
        NC["ব্যবহারকারী ডেটা জায়গা<br/>রান ২: অন্য জায়গার ধারাবাহিক ক্লাস্টার"]
        NA -->|"অবস্থান নির্দেশ"| NB
        NA -->|"অবস্থান নির্দেশ"| NC
    end

চিত্র ৩: রেসিডেন্ট ও নন-রেসিডেন্টের তুলনা। নন-রেসিডেন্টে রেকর্ড যা রাখে «সত্যি ডেটা কোথায় কত» সারণি (ডেটা রান) মাত্র

ডেটা রানের সংখ্যা বাড়লে এক ফাইল পড়তে ছড়ানো জায়গা ঘুরতে হয়। এটাই পরের খণ্ডীকরণের সত্তা।

এই কাঠামো থেকে মাঠে দেখা ঘটনা কয়েকটা ব্যাখ্যা যায়।

• ছোট ফাইল দশ হাজার কপি ধীর কেন। প্রতি ফাইলে MFT রেকর্ড তৈরি·নাম নিবন্ধন·নিরাপত্তা সেটিং মেটাডেটা অপারেশন হয়। ডেটা স্থানান্তর নিজে নয় খাতার কাজ প্রধান হয়ে যায় (আর তার প্রতিটা ৬ষ্ঠ কিস্তিতে দেখা ফিল্টারের পরীক্ষার লক্ষ্যও হয়)।
• খণ্ডীকরণের সত্তা। নন-রেসিডেন্ট ডেটা «ক্লাস্টারের ধারাবাহিক পরিসর (রান)-এর সারি» হিসেবে লেখা হয়। ধারাবাহিক জায়গা না পেলে রানের সংখ্যা বাড়ে, পড়ায় দরকারি সিক বাড়ে — এটাই খণ্ডীকরণ। রানের আসল সারি fsutil file layout দিয়ে দেখা যায়।
• «ফোল্ডার»ও বিশেষ নয়। ডিরেক্টরি «ফাইল নাম থেকে MFT রেকর্ড নম্বরে সূচি (ইনডেক্স) রাখা ফাইল»। খাতায় সব একই ব্যবস্থার উপর দাঁড়ায়।

3. ডেটা «স্ট্রিম»-এর একটা মাত্র

3.1. এক ফাইল, একাধিক বাইট সারি

NTFS-এ এক ফাইল একাধিক ডেটা স্ট্রিম রাখতে পারে। সাধারণত ReadFile/WriteFile দিয়ে পড়া-লেখা নামহীন ডিফল্ট স্ট্রিম, ফাইলনাম:স্ট্রিমনাম সিনট্যাক্সে অল্টারনেট ডেটা স্ট্রিম (ADS) বানানো যায়।²

flowchart LR
    subgraph F["report.docx নামের ফাইল (এক MFT রেকর্ড)"]
        D0["ডিফল্ট স্ট্রিম (নামহীন)<br/>= সাধারণত দেখা ভিতর"]
        D1[":Zone.Identifier<br/>উৎস তথ্য (Mark of the Web)"]
        D2[":যেকোনো নাম<br/>অ্যাপ নিজস্ব অতিরিক্ত তথ্য"]
    end

চিত্র ৪: একাধিক ডেটা স্ট্রিম। এক্সপ্লোরারের আকার প্রদর্শনে আসে শুধু ডিফল্ট স্ট্রিম

সবচেয়ে কাছের ADS Zone.Identifier। ব্রাউজারে ডাউনলোড ফাইলে এই স্ট্রিমে উৎস (ইন্টারনেট থেকে ইত্যাদি) লেখা হয়, SmartScreen-এর «Windows এই PC সুরক্ষা করেছে» বা Office সুরক্ষিত ভিউয়ের বিচারের উপাদান হয়। এই ব্যবস্থার বাইরের মুখ «Windows-এ «Windows এই PC সুরক্ষা করেছে» কেন ওঠে»-এ আছে — পেছনের সত্তা শুধু NTFS স্ট্রিম ছিল।

3.2. ডেভেলপার যে ফাঁদে পড়ে

• দেখা যায় না। এক্সপ্লোরারের আকারেও dir-এর তালিকায়ও আসে না। dir /r বা Sysinternals-এর streams দিয়ে দেখা যায়।¹¹
• সরানো যায় না। ADS NTFS-এর ফিচার, তাই FAT USB বা ক্লাউড স্টোরেজ দিয়ে কপিতে হারায় সহজে। «ডাউনলোড সতর্কতা কপি করলে মিলিয়ে গেল» এটাই।
• নিজের অ্যাপেও খোলা যায়। CreateFile("data.txt:meta", ...)-এর মতো পাথে কোলন দিলেই পড়া-লেখা যায়।² সুবিধা, কিন্তু আগের «সরানো যায় না» গুণও সঙ্গে নেয়, তাই ব্যবসায়িক ডেটার সত্তা রাখার জায়গা নয়।

4. নামও অ্যাট্রিবিউট — হার্ড লিঙ্ক ও 8.3 নাম

4.1. হার্ড লিঙ্ক — একই রেকর্ডে একাধিক নাম

চিত্র ২-এ «ফাইল নাম অ্যাট্রিবিউট একাধিক রাখা যায়» লিখেছি। একই ভলিউমের ভিতরে একাধিক পাথ এক ফাইল নির্দেশ করে — এটাই হার্ড লিঙ্ক (CreateHardLink / mklink /H)।³

flowchart TB
    subgraph DIR1["C:\app\ -এর ইনডেক্স"]
        E1["config.json → রেকর্ড#1234"]
    end
    subgraph DIR2["C:\backup\ -এর ইনডেক্স"]
        E2["config-link.json → রেকর্ড#1234"]
    end
    REC["MFT রেকর্ড#1234<br/>ডেটা সত্তা (বা রানের রেফারেন্স)<br/>লিঙ্ক সংখ্যা: 2"]
    E1 --> REC
    E2 --> REC

চিত্র ৫: হার্ড লিঙ্ক। ডিরেক্টরির সূচি একই MFT রেকর্ড নির্দেশ করে, দুটোই «আসল»

যেকোনো নাম থেকে বদলালেও একই ফাইল তাই ভিতর তৎক্ষণাৎ মিলে।³ আর «মুছা»-র অর্থ বদলায় — DeleteFile «নাম একটা খোলা», শেষ নাম খোলা, খোলা হ্যান্ডেল বন্ধ, আর মেমরি ম্যাপ সেকশন ইত্যাদি কার্নেলের ভিতর রেফারেন্সও সব মিলিয়ে গেলেই সত্তা যায়। ১ম কিস্তিতে দেখা cleanup (শেষ হ্যান্ডেল) ও close (শেষ রেফারেন্স) দুই ধাপ মুছার আয়ুতেও সরাসরি লাগে। অ্যাট্রিবিউট প্রদর্শনে অভ্যাস আছে, এক লিঙ্ক দিয়ে অ্যাট্রিবিউট বদলালে অন্য লিঙ্কের দেখা প্রদর্শন পুরনো থেকে যায় — এমন আচরণ সরকারিভাবে নোট আছে।³

4.2. 8.3 নাম — আর একটা লুকানো নাম

ঐতিহাসিক সামঞ্জস্যের জন্য NTFS লম্বা ফাইল নামের বিপরীতে REPORT~1.DOC ধরনের 8.3 ফর্ম্যাট সংক্ষিপ্ত নাম স্বয়ংক্রিয় তৈরি করতে পারে। এটাও «আর একটা নাম» হিসেবে রেকর্ডে পাশাপাশি। প্রচুর ফাইল আছে এমন ফোল্ডারে সংক্ষিপ্ত নাম তৈরি·সংঘাত এড়ানো খরচ হয়, তাই fsutil 8dot3name দিয়ে তৈরি নিষ্ক্রিয় বা বিদ্যমান সংক্ষিপ্ত নাম সরানো যায় (রেজিস্ট্রি পাথ সংক্ষিপ্ত নামে লেখা পুরনো অ্যাপ থাকলে ভাঙে, তাই strip-এর আগে পরীক্ষা ফাংশন থাকাও বাস্তব পয়েন্ট)।⁴

এখানে খেয়াল, সংক্ষিপ্ত নাম আছে কি না পরিবেশ নির্ভর। ডিফল্ট আচরণ রেজিস্ট্রি মান NtfsDisable8dot3NameCreation দিয়ে স্থির, 0 (সব ভলিউমে তৈরি), 1 (সব ভলিউমে তৈরি না), 2 (ভলিউম প্রতি সেটিং), 3 (সিস্টেম ভলিউম ছাড়া তৈরি না) চার পথ।⁴ 2 বাছলে ভলিউম প্রতি বদলানো যায়, তাই «Windows হলে PROGRA~1 ধরনের সংক্ষিপ্ত নাম অবশ্যই আছে» নয়। সংক্ষিপ্ত নামের উপর নির্ভর কোড বা ধাপ লেখার আগে fsutil 8dot3name query C: (ভলিউম বাদ দিলে সব ভলিউমের সাধারণ ডিফল্ট সেটিং) দিয়ে এখনকার অবস্থা নিশ্চিত করুন।

পাথ ও নাম ঘিরে ফাঁদ (MAX_PATH, সংরক্ষিত নাম, শেষে ডট) «MAX_PATH ও Windows পাথ·ফাইল নামের ফাঁদ»-এ বিস্তারিত। ১ম কিস্তির নাম সমাধান (অবজেক্ট ম্যানেজার) ও এই অধ্যায় (ফাইল সিস্টেমের ভিতর নাম) মিলিয়ে Windows-এর «নাম»-এর পুরো চিত্র হয়।

5. রিপার্স পয়েন্ট — «খুললে অন্য জায়গা»-র ব্যবস্থা

ফাইল বা ডিরেক্টরিতে রিপার্স পয়েন্ট লাগানো যায়। সত্তা «ট্যাগ + ব্যবহারকারী সংজ্ঞায়িত ডেটা» অ্যাট্রিবিউট। ফাইল সিস্টেম রিপার্স পয়েন্ট লাগানো ফাইল খুললে ট্যাগ অনুযায়ী প্রক্রিয়া কেড়ে নেওয়া হয় — ট্যাগ বোঝা ফিল্টার ড্রাইভার প্রক্রিয়া নেয়, অথবা নাম বদল ধরনের ট্যাগ হলে গন্তব্য পাথে সমাধান আবার হয়।⁵

sequenceDiagram
    participant App as অ্যাপ
    participant IOM as I/O ম্যানেজার
    participant FS as NTFS

    App->>IOM: CreateFile("C:\data\link.txt")
    IOM->>FS: IRP_MJ_CREATE (১ম কিস্তির জগৎ)
    Note over FS: লক্ষ্যে রিপার্স পয়েন্ট পাওয়া<br/>ট্যাগ ও ডেটা ফেরানো
    alt সিম্বলিক লিঙ্ক/জাংশন (নাম বদল)
        FS-->>IOM: «আসল জায়গা এদিকে»
        IOM->>FS: গন্তব্য পাথে সমাধান আবার
    else ফিল্টার ব্যবস্থাপনার ট্যাগ (ক্লাউড ফাইল ইত্যাদি)
        Note over FS: ট্যাগ বোঝা ফিল্টার<br/>প্রক্রিয়া নেয় (৬ষ্ঠ কিস্তি)
    end

চিত্র ৬: রিপার্স পয়েন্টের সমাধান। «খোলা» অপারেশনে ঢোকার সরকারি হুক

এই এক ব্যবস্থার উপর চেনা ফিচার সারিবদ্ধ।

• সিম্বলিক লিঙ্ক (mklink) — গন্তব্য পাথ রাখা সাইনবোর্ড। অন্য ভলিউম বা UNC পাথও নির্দেশ করতে পারে।⁶
• জাংশন/মাউন্ট পয়েন্ট — ডিরেক্টরি অন্য স্থানীয় ভলিউমের অবস্থানে যোগ করার পুরনো ব্যবস্থা।³
• OneDrive ফাইল অন ডিমান্ড — সত্যি ডেটা হাতে নেই ফাইল রিপার্স পয়েন্টে প্রকাশ করে, খোলার মুহূর্তে ফিল্টার ডাউনলোড করে ভিতর এগিয়ে দেয়। «এক্সপ্লোরারে দেখা যায় কিন্তু খুললে যোগাযোগ চলে»-এর সত্তা (ফিল্টার ব্যবস্থা নিজে ৬ষ্ঠ কিস্তিতে)।

বাস্তব সতর্কতা একটা। «পাথের সামনে সত্যি স্থানীয় সেই জায়গা এমন নয়»। পুনরাবৃত্তি করে ট্রি ঘোরা টুল জাংশনে লুপ করে, আকার যোগ দ্বৈত হয়, ব্যাকআপ ক্লাউড সত্তাকরণ প্রচুর জন্মায় — রিপার্স পয়েন্ট না জানা কোড এগুলোতে পড়ে। FindFirstFile পরিবারের অ্যাট্রিবিউট FILE_ATTRIBUTE_REPARSE_POINT নিশ্চিতকরণ মোকাবিলার প্রবেশ।⁵

6. দুই জার্নাল — $LogFile ও USN

«NTFS জার্নালিং ফাইল সিস্টেম» বলা হয়, কিন্তু NTFS-এ ভূমিকা আলাদা দুই জার্নাল আছে। গুলিয়ে গেলে গ্যারান্টি ভুল পড়া হয়।

flowchart TB
    subgraph J1["$LogFile ── অগ্রবর্তী লগ (না ভাঙার জন্য)"]
        A1["মেটাডেটা অপারেশন (রেকর্ড হালনাগাদ·নাম বদল ইত্যাদি)<br/>চালানোর আগে লগে লেখা"]
        A2["সিস্টেম বিঘ্নের পর পরের চালুতে<br/>লগ পুনরায় চালিয়ে কাঠামোর সামঞ্জস্য পুনরুদ্ধার"]
        A1 --> A2
    end
    subgraph J2["USN জার্নাল ── বদলের ইতিহাস (কী বদলেছে জানার জন্য)"]
        B1["ফাইল/ডিরেক্টরিতে বদল প্রতি<br/>বদলের ভিতর ও নাম লেখা"]
        B2["ব্যাকআপ·সার্চ ইনডেক্স·সিঙ্ক টুল<br/>«আগের থেকে কী বদলেছে» পুরো স্ক্যান ছাড়া ধরে"]
        B1 --> B2
    end

চিত্র ৭: দুই জার্নাল। $LogFile «না ভাঙার জন্য», USN «বদল জানার জন্য»

ফারাক সারণিতে এমন।

সারণি ২: দুই জার্নালের তুলনা

• $LogFile (লেনদেন লগ) মেটাডেটা অপারেশনের অগ্রবর্তী লগ। সিস্টেম বিঘ্ন হলেও NTFS পরের চালুতে এই লগ ও চেকপয়েন্ট তথ্য থেকে ফাইল সিস্টেমের সামঞ্জস্য স্বয়ংক্রিয় পুনরুদ্ধার করে।⁷ এখানে যা রক্ষা হয় কাঠামো। ৪র্থ কিস্তিতে দেখা অনুযায়ী ক্যাশে ডার্টি ডেটার ভিতর পাওয়ার কাটে হারাতে পারে — «ভলিউম ভাঙে না। কিন্তু শেষ লেখা হারাতে পারে» সঠিক পড়া।
• USN জার্নাল (বদল জার্নাল) ভলিউমের ফাইল বা ডিরেক্টরিতে বদল হলেই বদলের ভিতর ও লক্ষ্যের নাম লিখে যাওয়া খাতা।⁸ ব্যাকআপ বা ইনডেক্সার «আগের থেকে বদলানোগুলোই» পুরো স্ক্যান ছাড়া তোলার ব্যবস্থা, বিঘ্নের পর ইনডেক্স পুনর্নির্মাণ এড়াতেও ব্যবহার হয়।⁸ বাস্তবে FileSystemWatcher-এর হারানো («FileSystemWatcher বাস্তব নির্দেশিকা») পূরণের মিলানো খাতা হিসেবে fsutil usn readjournal তদন্তে ব্যবহার যায় মনে রাখলে কাজে লাগে।

7. স্পার্স ও কম্প্রেশন — «আকার» দুটো থাকার কথা

NTFS-এ ফাইলের লজিক্যাল দৈর্ঘ্য ও সত্যি বরাদ্দ জায়গা আলাদা সামলানো হয়। প্রপার্টি পর্দার «আকার» ও «ডিস্কে আকার»। ফারাক জন্মানোর প্রতিনিধি দুটো।

স্পার্স ফাইল শূন্য চলা পরিসরে সত্যি জায়গা বরাদ্দ না করে «গর্ত» হিসেবে সামলায়।⁹ লজিক্যাল আকার 42GB ভার্চুয়াল ডিস্ক ফাইল ডিস্কে 500MBই ব্যবহার — সাধারণ ঘটে। গর্ত পড়লে শূন্য ফেরে, লিখলে সেই পরিমাণ বরাদ্দ হয়।

flowchart LR
    subgraph L["লজিক্যাল ফাইল (আকার: 1GB)"]
        R1["ডেটা 10MB"]
        H1["গর্ত (শূন্য) 500MB"]
        R2["ডেটা 5MB"]
        H2["গর্ত (শূন্য) বাকি"]
    end
    subgraph P["ডিস্কে বরাদ্দ (15MB+ব্যবস্থাপনা তথ্য)"]
        A1["রান: R1-এর সত্তা"]
        A2["রান: R2-এর সত্তা"]
    end
    R1 --> A1
    R2 --> A2

চিত্র ৮: স্পার্স ফাইল। «গর্ত»-এ বরাদ্দ নেই, লজিক্যাল আকার ও ডিস্কে আকার ফারাক হয়

NTFS কম্প্রেশন ডেটা কম্প্রেশন ইউনিট এককে কম্প্রেস করে রাখে।¹⁰ স্বচ্ছ সুবিধা, কিন্তু খরচও স্বচ্ছ নয় — পড়া-লেখা প্রতি প্রসারণ·পুনরায় কম্প্রেশন চলে, খণ্ডীকরণও সহজে এগোয়। আর ২য় কিস্তি ৫ অধ্যায়-এ দেখা অনুযায়ী কম্প্রেসড ফাইলে অ্যাক্সেস অ্যাসিঙ্ক্রোনাস হয় না (ফাইল সিস্টেম সিঙ্ক্রোনাসে রূপান্তর করে)। «অ্যাসিঙ্ক্রোনাস I/O করলাম তবু তাড়াতাড়ি হয় না ফাইল আছে» তখন সন্দেহের এক জায়গা।

বরাদ্দ ভিত্তিক সত্যি আকার GetCompressedFileSize দিয়ে পাওয়া যায়। «ফাইল আকারের যোগ» আর «ডিস্ক ব্যবহার» মেলে না তদন্তে স্পার্স·কম্প্রেশন·ADS (৩ অধ্যায়)·ক্লাস্টার গোল চারটা ক্রমে সন্দেহ করাই নিয়ম।

8. নিজের চোখে নিশ্চিত করা

এবারও হাতের Windows-এ সব পর্যবেক্ষণ যায় (কিছুতে প্রশাসক অধিকার লাগে)। চালানো ফল সঠিক কি না নিজে বিচার করতে কমান্ড প্রতি কোথায় দেখলে কী বোঝা যায় যোগ করি।

:: অল্টারনেট ডেটা স্ট্রিম দেখা
dir /r C:\Users\%USERNAME%\Downloads

এখানে দেখুন: সাধারণ ফাইল সারির নিচে ইন্ডেন্ট করা ফাইলনাম:Zone.Identifier:$DATA ফর্ম্যাটের সারি দৈর্ঘ্যসহ সারিবদ্ধ। এই সারি থাকলে সেই ফাইলে Mark of the Web লাগানো অবস্থা (৩ অধ্যায়)। ব্রাউজারে ডাউনলোড ফাইলে লাগে, নিজে বানানো ফাইলে লাগে না। দুই জায়গায় চালিয়ে তুলনা করলে ADS আছে কি না স্পষ্ট হয়।

:: ফাইলের MFT-এর বিন্যাস(রান) ও অ্যাট্রিবিউট দেখা
fsutil file layout C:\path\to\file.dat

:: শুধু এক্সটেন্ট দেখা (সরকারি নথিতে লেখা সাবকমান্ড)
fsutil file queryextents C:\path\to\file.dat

এখানে দেখুন: layout স্ট্রিম প্রতি আকার·বরাদ্দ আকার ও নন-রেসিডেন্ট হলে এক্সটেন্ট (VCN·LCN·ক্লাস্টার সংখ্যার জোড়া) তালিকা সাজায়। এক্সটেন্ট সারি না আসা খুব ছোট ফাইল রেসিডেন্ট (২.২ অধ্যায়), একাধিক সারিতে ভাগ থাকলে খণ্ডীকৃত। কয়েক বাইটের টেক্সট ফাইল ও কয়েকশ MB ফাইলে চালিয়ে তুলনা করা রেসিডেন্ট/নন-রেসিডেন্ট সবচেয়ে ছোট পথে অনুভব করার পথ।

:: 8.3 সংক্ষিপ্ত নাম তৈরির সেটিং ও বিদ্যমান সংক্ষিপ্ত নাম
fsutil 8dot3name query C:
dir /x

এখানে দেখুন: query সেই ভলিউমে সংক্ষিপ্ত নাম তৈরি চালু কি নিষ্ক্রিয় ফেরায় (ভলিউম বাদ দিলে সব ভলিউমের সাধারণ ডিফল্ট সেটিং)।⁴ dir /x লম্বা নামের পাশে সংক্ষিপ্ত নামের কলাম দেখায়, কলাম ফাঁকা হলে সংক্ষিপ্ত নাম তৈরি হয়নি। ৪.২ অধ্যায়ের «সংক্ষিপ্ত নাম আছে এমন নয়» নিজের পরিবেশে নিশ্চিত করা যায়।

:: USN জার্নালের অবস্থা
fsutil usn queryjournal C:

এখানে দেখুন: জার্নাল ID, বৈধ USN পরিসর (First USN / Next USN), লক্ষ্য সর্বোচ্চ আকার (MaximumSize) ও বরাদ্দ একক (AllocationDelta) দেখা যায়।¹² কোনো ফাইল বানিয়ে আবার চালালে Next USN এগোবে, এটাই «বদল রেকর্ড হচ্ছে» নিশ্চিতকরণ। MaximumSize ৬ অধ্যায়ে বলা «কতদূর পেছনে যাওয়া যায়»-এর আন্দাজ। জার্নাল নিষ্ক্রিয় ভলিউমে ত্রুটি হয়।

:: রিপার্স পয়েন্টের নিশ্চিতকরণ (লিঙ্ক গন্তব্য ও ট্যাগ)
dir /aL C:\Users\%USERNAME%
fsutil reparsepoint query "C:\Users\%USERNAME%\OneDrive"

এখানে দেখুন: dir /aL-এ যা আসে রিপার্স পয়েন্ট (FILE_ATTRIBUTE_REPARSE_POINT দাঁড়ানো)। সিম্বলিক লিঙ্ক বা জাংশন <SYMLINKD> <JUNCTION> ধরনের ধরনসহ দেখা যায়। fsutil reparsepoint query রিপার্স ট্যাগের মান ও নাম বদল ধরন হলে গন্তব্য পাথ দেখায়। রিপার্স পয়েন্ট নয় এমন লক্ষ্য নির্দিষ্ট করলে ত্রুটি হয়, তাই ত্রুটি হওয়া নিজেই «এখানে সাধারণ ফোল্ডার» নিশ্চিতকরণ।

Procmon দিয়ে ফাইল অপারেশন তাড়ালে এবারের চরিত্ররা আসল নামে বয়ে ($LogFile-এ লেখা, স্ট্রিম নামসহ পাথ, রিপার্স প্রক্রিয়া)। ব্যবহার «Process Monitor (ProcMon) বাস্তব নির্দেশিকা» দেখুন।

9. সারসংক্ষেপ

• NTFS-এর কেন্দ্র MFT। সব ফাইল খাতার রেকর্ড, তথ্য «রেকর্ডের ভিতরে» বা «রেকর্ড নির্দেশ করা বাইরের জায়গায়»। ছোট ডেটা রেসিডেন্ট, বড় ডেটা রান রেফারেন্স, ছোট ফাইল প্রচুর প্রক্রিয়ার ধীরতা ও খণ্ডীকরণ এই কাঠামোর ফল।¹
• ডেটা স্ট্রিম একাধিক রাখা যায়। Zone.Identifier (Mark of the Web) শুধু ADS, dir /r দিয়ে দেখা যায়, NTFS-এর বাইরে যায় না।²¹¹
• নাম অ্যাট্রিবিউট, একাধিক রাখা যায়। হার্ড লিঙ্ক একই রেকর্ডে সমমর্যাদার নাম, 8.3 নাম সামঞ্জস্যের আর একটা নাম। «মুছা = নাম খোলা», সত্তা মিলিয়ে যাওয়া শেষ নাম·হ্যান্ডেল·কার্নেলের ভিতর রেফারেন্স (ম্যাপ সেকশন ইত্যাদি) সব না থাকলেই।³⁴
• রিপার্স পয়েন্ট «খোলা»-র সরকারি হুক, সিম্বলিক লিঙ্কও জাংশনও ফাইল অন ডিমান্ডও এই প্রয়োগ। ট্রি ঘোরা কোড FILE_ATTRIBUTE_REPARSE_POINT সচেতন হওয়া লাগে।⁵⁶
• জার্নাল দুটো। $LogFile কাঠামোর সামঞ্জস্য পুনরুদ্ধার (না ভাঙা), USN বদলের ইতিহাস (কী বদলেছে)। «জার্নালিং তাই ডেটাও নিরাপদ» নয় — ডেটার স্থায়িত্ব ৪র্থ কিস্তির টুলে বানান।⁷⁸
• লজিক্যাল আকার ও বরাদ্দ আলাদা। স্পার্স·কম্প্রেশন·ADS·ক্লাস্টার গোল «আকার মেলে না»-র চার বড় কারণ। কম্প্রেসড ফাইল অ্যাসিঙ্ক্রোনাস I/O হয় না বিষয়সহ পারফরম্যান্স তদন্তের ড্রয়ার।⁹¹⁰

পরেরটা শেষ কিস্তি, ৬ষ্ঠ কিস্তি «ফিল্টার ড্রাইভার ও মিনিফিল্টার — Procmon ও ভাইরাস স্ক্যান I/O-তে কেন ঢুকতে পারে»। ১ম কিস্তি থেকে মাঝে মাঝে দেখা «মাঝে ঢোকা চরিত্ররা» — ভাইরাস প্রতিরোধ, Procmon, OneDrive, এনক্রিপশন — কীভাবে I/O-তে ঢোকে। ধারাবাহিকের শেষ সাজ হিসেবে ডিভাইস স্ট্যাকের ফাঁকে দাঁড়ানো বাসিন্দাদের সত্তা খুলি।

সম্পর্কিত নিবন্ধ

• Windows I/O-এর গভীরতা (১ম কিস্তি) — সব পড়া-লেখা IRP হয়: I/O সিস্টেমের পুরো চিত্র
• Windows I/O-এর গভীরতা (২য় কিস্তি) — সিঙ্ক্রোনাস I/O ও অ্যাসিঙ্ক্রোনাস I/O: OVERLAPPED-এর আসল অর্থ
• Windows I/O-এর গভীরতা (৪র্থ কিস্তি) — ক্যাশ ম্যানেজার: আপনার WriteFile কখন ডিস্কে পৌঁছায়
• Windows-এ «Windows এই PC সুরক্ষা করেছে» কেন ওঠে
• MAX_PATH ও Windows পাথ·ফাইল নামের ফাঁদ — ২৬০ অক্ষর সীমা, সংরক্ষিত নাম, শেষে ডট, বড়-ছোট হাত
• FileSystemWatcher বাস্তব নির্দেশিকা — হারানো ও দ্বৈত মোকাবিলা
• নেটওয়ার্ক ড্রাইভ ও UNC পাথের ফাঁদ — ব্যবসায়িক অ্যাপে ফাইল সার্ভার (শেয়ার ফোল্ডার) সামলানোর বাস্তব
• Process Monitor (ProcMon) বাস্তব নির্দেশিকা — «সেটিং পড়া হয় না» «ACCESS DENIED» ১০ মিনিটে শনাক্ত

সম্পর্কিত পরামর্শ ক্ষেত্র

KomuraSoft LLC ফাইল আকার বা কপি পারফরম্যান্সের অদ্ভুত আচরণ, লিঙ্ক·স্ট্রিম জড়ানো বাগ ইত্যাদি NTFS-এর ব্যবস্থায় শিকড় থাকা Windows ব্যবসায়িক অ্যাপের নকশা·তদন্ত সামলায়।

• Windows অ্যাপ ডেভেলপমেন্ট
• বাগ ও কারণ তদন্ত
• বিদ্যমান অ্যাসেটের পুনর্ব্যবহার ও মাইগ্রেশন
• যোগাযোগ করুন

তথ্যসূত্র

সম্পর্কিত নিবন্ধ

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

সম্পর্কিত বিষয়

এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।

এই বিষয়ের সাথে সম্পর্কিত সেবা

নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।

প্রায়শ জিজ্ঞাসিত প্রশ্ন

এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।

MFT (মাস্টার ফাইল টেবিল) কী?

NTFS ভলিউমের হৃদয়ের ডেটা কাঠামো, ভলিউমের সব ফাইলের জন্য অন্তত একটা এন্ট্রি (ফাইল রেকর্ড) রাখা খাতা। MFT নিজের এন্ট্রিও আছে। ফাইলের আকার, টাইমস্ট্যাম্প, অ্যাক্সেস অনুমতি, ডেটা সত্তা পর্যন্ত ফাইল সম্পর্কিত সব তথ্য MFT এন্ট্রির ভিতরে বা MFT এন্ট্রি যে MFT-এর বাইরের জায়গা নির্দেশ করে সেখানে থাকে। ছোট ফাইল হলে ডেটা সত্তাসহ MFT এন্ট্রির ভিতরে ধরে (রেসিডেন্ট), বড় ফাইলে ডেটার জায়গা (ক্লাস্টার সারি)-এর রেফারেন্সই এন্ট্রিতে লেখা হয় (নন-রেসিডেন্ট)। ফাইল মুছলে এন্ট্রি ফাঁকা চিহ্নিত হয়ে পুনর্ব্যবহার হয়, কিন্তু MFT নিজের আকার ছোট হয় না।

ফাইলে লাগানো «Zone.Identifier» অদেখা ডেটা কী?

NTFS-এর একাধিক ডেটা স্ট্রিম (অল্টারনেট ডেটা স্ট্রিম)-এর একটা। NTFS-এ এক ফাইল একাধিক বাইট সারি (স্ট্রিম) রাখতে পারে, সাধারণত পড়া-লেখা করাটা নামহীন ডিফল্ট স্ট্রিম। «file.txt:Zone.Identifier»-এর মতো কোলন দিয়ে নির্দিষ্ট অতিরিক্ত স্ট্রিমে Windows ফাইলের উৎস (ইন্টারনেট থেকে ডাউনলোড ইত্যাদি) লেখে। এটাই তথাকথিত «Mark of the Web», SmartScreen সতর্কতা ও Office সুরক্ষিত ভিউয়ের বিচারের উপাদান। অল্টারনেট স্ট্রিম এক্সপ্লোরারের আকার প্রদর্শনে আসে না, dir /r কমান্ড বা Sysinternals-এর streams টুলে দেখা যায়। NTFS ছাড়া ফাইল সিস্টেমে (FAT ইত্যাদি) কপি করলে রাখা হয় না — এটাও খেয়াল রাখুন।

হার্ড লিঙ্ক আর সিম্বলিক লিঙ্কের ফারাক কী?

হার্ড লিঙ্ক «একই ফাইল সত্তা (একই MFT রেকর্ড) নির্দেশ করা সমমর্যাদার নাম আর একটা বাড়ে»। একই ভলিউমের ভিতরেই বানানো যায়, যেকোনো নাম থেকে অ্যাক্সেস একই ফাইল, একটা নাম মুছলেও অন্য নাম থাকলে ফাইল যায় না। সিম্বলিক লিঙ্ক «অন্য পাথে নিয়ে যাওয়া সাইনবোর্ড», রিপার্স পয়েন্ট হিসেবে বাস্তবায়িত। লিঙ্ক গন্তব্যের পাথ স্ট্রিংই রাখে, তাই অন্য ভলিউম বা রিমোটও নির্দেশ করতে পারে, কিন্তু গন্তব্য মিলিয়ে গেলে পথ শেষ। বাস্তবে হার্ড লিঙ্ক সত্তা ভাগ (মুছার অর্থ বদলায়), সিম্বলিক লিঙ্ক পাথ বদল (সরানো বা রিডাইরেক্ট) — এই ভাগই মূল।

NTFS জার্নালিং ফাইল সিস্টেম, তাই পাওয়ার কাটলেও ডেটা হারায় না?

কী রক্ষা হয় সঠিক বোঝা লাগে। NTFS-এর লেনদেন লগ ($LogFile) রক্ষা করে ফাইল সিস্টেমের কাঠামো (মেটাডেটা)-এর সামঞ্জস্য। সিস্টেম বিঘ্ন হলেও পরের চালুতে লগ দিয়ে সামঞ্জস্য স্বয়ংক্রিয় পুনরুদ্ধার করে, «ভলিউম ভেঙে পড়া যায় না» অবস্থা ঠেকায়। কিন্তু লেখার মাঝে থাকা ফাইলের ডেটা ভিতর নিজে পুনরুদ্ধার হয় না। ধারাবাহিকের ৪র্থ কিস্তিতে দেখা অনুযায়ী ক্যাশে ডার্টি ডেটা পাওয়ার কাটে হারায়। অর্থাৎ «ভলিউম ভাঙে না, কিন্তু শেষ লেখার ভিতর হারাতে পারে» সঠিক বোঝা, ডেটা নিজের স্থায়িত্ব লাগলে FlushFileBuffers বা WRITE_THROUGH, অথবা অ্যাপ পাশের লেখার নকশা (অস্থায়ী ফাইল+নাম বদল ইত্যাদি) দিয়ে বানাতে হয়।

ফাইলের «আকার» আর «ডিস্কে আকার» আলাদা কেন?

NTFS-এ ফাইলের লজিক্যাল দৈর্ঘ্য ও সত্যি বরাদ্দ ডিস্ক জায়গা আলাদা সামলানো হয়। সাধারণ ফাইলেও ক্লাস্টার এককে (ডিফল্ট 4KB) উপরে গোল করে বরাদ্দ তাই ফারাক হয়, বড় ফারাক স্পার্স ফাইল ও কম্প্রেসড ফাইলে। স্পার্স ফাইলে শূন্য চলা পরিসরে সত্যি জায়গা বরাদ্দ না করে «গর্ত» হিসেবে সামলায়, তাই লজিক্যাল আকার কয়েক GB হলেও ডিস্কে কয়েক MB হতে পারে। কম্প্রেসড ফাইলে কম্প্রেশনের পরের আকারই বরাদ্দ। উল্টে «ডিস্কে আকার» বড় দেখালে ক্লাস্টার গোল বা অল্টারনেট ডেটা স্ট্রিম কারণ হতে পারে।

লেখকের প্রোফাইল

নিবন্ধের লেখকের পরিচিতি পৃষ্ঠা।

Go Komura

KomuraSoft LLC-এর প্রতিনিধি

Windows সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।