Windows I/O की गहराई (भाग 4) — Cache Manager: आपका WriteFile disk तक कब पहुँचता है

WriteFile success return किया। तो data अभी कहाँ है?

उत्तर, लगभग निश्चित अभी disk पर नहीं। Memory के cache में copy मात्र। इसलिए «save किया, बिजली कटने पर लौटे तो गया» होता है; इसलिए file copy benchmarks physically असंभव गति दिखाते हैं; इसलिए databases ईमानदारी से fsync बुलाते हैं।

Series «Windows I/O की गहराई» का भाग 4 इस बीच खड़े Cache Manager पर है। भाग 2 में «cache पर हो तो async I/O भी sync complete» लिखा, भाग 1 में «IRP न बनाने वाला shortcut (fast I/O)» homework छोड़ा। इस बार वे कड़ियाँ समेटते हैं।

1. निष्कर्ष पहले

• Windows file cache write-back तरीके से काम करता है। Read पहले system file cache से, write भी पहले cache पर। Disk पर reflect OS बाद करता है।¹
• Cache का पदार्थ file mapping है। Cache Manager file के 256KB खंड system address space पर map करता है, read-write «उस view और app buffer के बीच memory copy» बनता है (अध्याय 2)।¹
• Write हर सेकंड lazy writer पीछे से reflect करता है। App crash पर data नहीं जाता, पर power loss या OS crash पर dirty cache जाता है (अध्याय 4)।¹
• «पक्का लिखना» तीन tools। FlushFileBuffers (= .NET का Flush(true)), FILE_FLAG_WRITE_THROUGH, FILE_FLAG_NO_BUFFERING। बार-बार लिखने पर हर बार flush inefficient, official documentation NO_BUFFERING+WRITE_THROUGH साथ गिनाता है (अध्याय 5)।²¹
• NO_BUFFERING पर alignment requirement है। Size-offset sector size का exact multiple, buffer address भी physical sector boundary पर aligned। और NO_BUFFERING पर भी metadata cache होता रहता है (अध्याय 5.3)।³¹
• Map view और cache वही data share करते हैं। Memory-mapped file और सामान्य cache I/O coherent, map durability FlushViewOfFile+FlushFileBuffers दो चरण (अध्याय 6)।⁴⁵
• Cache पर sync read-write IRP भी न बनाए। Fast I/O shortcut Cache Manager सीधा जाता है — भाग 1 homework का उत्तर (अध्याय 7)।⁶

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 32, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. Cache का असली रूप — file memory पर map होती है

2.1. 256KB slots और memory copy

Windows file cache «disk block का बर्तन» सोचें तो कई व्यवहार समझ नहीं आते। सही चित्र यह — Cache Manager file के 256KB खंड system address space के «slots» पर map करता है, cache-enabled read-write उस slot और app buffer के बीच memory copy के रूप में चलता है।¹

flowchart TB
    subgraph U["App (user mode)"]
        BUF["App का buffer<br/>(ReadFile/WriteFile को दिया क्षेत्र)"]
    end
    subgraph S["System address space"]
        SLOT["System file cache<br/>File के 256KB खंड map किया slot"]
    end
    DISK[("Disk पर file")]
    BUF <-->|"ReadFile/WriteFile =<br/>slot के बीच memory copy"| SLOT
    SLOT <-->|"पहली पहुँच पर पढ़ना और<br/>पीछे लिखना page इकाई"| DISK

चित्र 1: Cache-enabled I/O का यथार्थ। App से देखा «file read-write» अधिकतर साधारण memory copy

गलत समझ एक। 256KB view (map) की granularity है, disk I/O हमेशा 256KB इकाई चले — यह अर्थ नहीं। Slot के pages आवश्यकतानुसार पढ़े जाते हैं, वास्तव में disk पर जाने वाला I/O मात्रा request size और access pattern से बदलती है। पहली बार पढ़े खंड पर भरने को disk I/O (यहाँ भाग 1 का IRP नीचे storage stack जाता है)। पहले से cache हो तो read copy मात्र से complete। भाग 2 अध्याय 5 का «cache hit पर async जारी करें तो भी sync complete» यही «तुरंत उत्तर दे सकें तो वहीं complete» चाल का प्रकटन था। उलटा, cache-enabled रह page memory पर न हो तो page fault processing में async mechanism नहीं, async read sync processed हो सकता है — यह जाल भी भाग 2 में।⁷

2.2. «Free memory घटी» का असली रूप

Cache use और read-ahead अवस्था खोलने के तरीके (file object इकाई) से managed¹, पर cache data पदार्थ file (stream) इकाई share। वही file बार खोलें तो अलग cache नहीं बनते, किसी भी handle से वही cache content दिखती है (अध्याय 6 coherency का आधार)। Cache Windows चलते Cache Manager कमान में रहता है।¹ बड़ी file copy या बहुत read-write करें तो free physical memory cache में बदलती जाती है। Task Manager free memory घटी दिखे, अधिकतर «app माँगे तो जल्दी सौंपे जाने वाला, मूल्यवान use में standby memory» है। Memory shortage diagnosis में यह भेद न गलती करने को observation व्यवहार «.NET में GC wait और memory leak अलग करना» में भी है।

यह चाल screen पर जाँच सकते हैं। Task Manager > Performance > Memory खोलें, नीचे «Memory composition» bar In use / Modified / Standby / Free बँटा है। File cache अधिकतर इस Standby में जाता है, दाईं list में «Cached» योग। और बारीक Resource Monitor > Memory tab, वही विभाजन मात्रा सहित। कई GB file एक copy कर फिर देखें — Standby बढ़े, Free घटे, «In use» लगभग न बदले — यानी «memory खाई गई» नहीं «free memory cache बनी» आँख से पुष्ट।

3. Read-ahead — पढ़ने की सट्टेबाज़ी

Cache Manager पिछले access pattern से आगे पढ़े जाने वाले खंड पहले से पढ़ता है (read-ahead)। क्रम से पढ़ी file पर app माँगने से पहले आगे का data पहले से cache — यही sequential read की गति का रहस्योद्घाटन। Read-ahead मात्रा स्थिर नहीं, पकड़े pattern और request size से बदलती है।

flowchart LR
    A["App पढ़ने के request का इतिहास<br/>आरंभ से क्रम से पढ़ रहा है"]
    D{"Cache Manager<br/>pattern पकड़ता है"}
    R["Read-ahead: आगे का खंड<br/>माँगने से पहले पढ़कर रखता है<br/>(मात्रा pattern और request size से परिवर्तनीय)"]
    H1["Hint FILE_FLAG_SEQUENTIAL_SCAN<br/>= read-ahead सक्रिय"]
    H2["Hint FILE_FLAG_RANDOM_ACCESS<br/>= read-ahead व्यर्थ, दबाएँ"]
    A --> D
    D --> R
    H1 -.-> D
    H2 -.-> D

चित्र 2: Read-ahead। Access pattern पकड़ने के साथ CreateFile flags से hint दे सकते हैं

भाग 1 तालिका के FileOptions.SequentialScan / RandomAccess इसी read-ahead engine के hints हैं। «सब चाटना» batch processing पर पहला, index घूमने जैसी पहुँच पर दूसरा — app ही जानता भविष्य OS को बताने वाले flags सोचें तो use स्थान स्पष्ट।

4. Lazy writing — WriteFile «success» का अर्थ

4.1. lazy writer हर सेकंड आता है

लिखने वाला पक्ष write-back cache है। WriteFile data slot पर copy होते success return करता है, disk reflect बाद। यह «देर से लिखना» नीति lazy writing है।¹

Reflect चलाता Cache Manager हर सेकंड चला lazy writer। हाल flush न हुए pages का 1/8 queue में रखकर लिखता है, लिखने योग्य data अधिक हो तो और बढ़ाता है। FILE_ATTRIBUTE_TEMPORARY attribute सहित बनी temporary file lazy writer flush लक्ष्य से बाहर — जल्दी मिटने वाली लिखना व्यर्थ।¹ पर यह attribute द्वारा hint है, memory तंग हो तो लिखी जा सकती है, और «नाम temporary जैसा» file पर apply नहीं।

sequenceDiagram
    participant App as App
    participant C as System cache
    participant LW as lazy writer (हर सेकंड)
    participant D as Disk

    App->>C: WriteFile (data)
    Note over C: Slot पर copy कर<br/>page dirty (न लिखा) चिह्नित
    C-->>App: तुरंत TRUE return करता है
    Note over App,C: यहाँ से लिखने तक «खतरनाक खिड़की»<br/>Power loss · OS crash पर यह data जाता है
    LW->>C: Dirty pages का 1/8 चुनता है
    LW->>D: एकत्र लिखता है
    Note over D: यहीं पहली बार durable होता है

चित्र 3: Lazy writing। WriteFile success «OS को सौंपा» है, «durable हुआ» नहीं

4.2. क्या हो तो कितना जाता है

«खतरनाक खिड़की» अर्थ सटीक करें। Failure type से नियति बँटती है।

flowchart TB
    W["WriteFile सफल तुरंत बाद का data<br/>(Cache पर dirty page)"]
    Q{"क्या हुआ"}
    A1["App process<br/>crash / forcibly terminate"]
    A2["OS सहित रुकना<br/>(Power loss · blue screen)"]
    S["Data बचता है<br/>Cache OS का है इसलिए<br/>lazy writer नियत लिखता है"]
    L["Dirty page जाता है<br/>Disk तक पहुँचा भाग मात्र बचता है"]
    W --> Q
    Q --> A1
    Q --> A2
    A1 --> S
    A2 --> L

चित्र 4: Failure type और बचने का विभाजन। Cache «process की संपत्ति» नहीं «OS की संपत्ति»

• App मरे data नहीं जाता। Cache copy complete होते data स्वामी OS। «Save करते app गिरा file सुरक्षित» इसी कारण।
• OS सहित मरे dirty भाग जाता है। Flush आवृत्ति performance और reliability के समझौते के रूप में समायोजित, «अचानक power loss पर cache data जाता है» documentation भी स्पष्ट कहता है।¹

यानी business apps design का प्रश्न, «यह data बिजली कटने के क्षण जा सकता है?» Log के कुछ सेकंड क्षमा हो सकते हैं। Order data का निश्चित record नहीं। न क्षमा योग्य पर अगले अध्याय के tools।

5. «पक्का लिखा» बनाने का toolbox

5.1. FlushFileBuffers — अभी लिख डालें

FlushFileBuffers निर्दिष्ट file का buffered data device तक लिख देता है। File system metadata हमेशा cache होता है, इसलिए metadata तक पक्का पहुँचाने को flush (या WRITE_THROUGH) चाहिए — यह भी पकड़ने योग्य बिंदु।¹² .NET में FileStream.Flush(true) इसके बराबर (Flush() अकेले .NET internal buffer OS को सौंपता है, OS cache ज्यों का त्यों)।⁸

पर official documentation स्पष्ट कील ठोंकता है — लिखने हर बार बुलाना inefficient। अनेक लिखने पर हर बार durability चाहिए तो बाद के NO_BUFFERING+WRITE_THROUGH use करें।²

5.2. FILE_FLAG_WRITE_THROUGH — delay मात्र हटाना

FILE_FLAG_WRITE_THROUGH से खोलें तो लिखना cache पर भी लिखा जाता है, lazy writer wait बिना तुरंत disk पर भी।¹ Read cache फ़ायदा लेता रहता है — «read तेज़ रहे, लिखने की delay मात्र हटे» का सीधा उत्तर।

5.3. FILE_FLAG_NO_BUFFERING — cache से नहीं गुज़रना

FILE_FLAG_NO_BUFFERING read-write से system cache स्वयं बाहर करता है। सब read-write cache बिना हर बार disk device I/O।¹ पर छोड़ सकने वाला Windows system cache तक, चित्र 5 के अनुसार device भीतर लिखने का cache अलग चरण। Power loss तक प्रतिरोध चाहिए तो WRITE_THROUGH साथ या FlushFileBuffers अभी चाहिए। बड़ी data एकमुश्त transfer या स्वयं buffer management करने वाले database engines का tool, पर सख्त वादे साथ।³

• Read-write का size और file offset volume sector size का exact multiple (512-byte sector पर 512 · 1024 · 1536…)।
• Buffer address भी physical sector size पर aligned (4096-byte physical sector «Advanced Format» disk का भी ध्यान)।
• तब भी metadata cache होता रहता है, पूर्ण durability को WRITE_THROUGH साथ या FlushFileBuffers चाहिए।¹²

यह «वादा» flag जोड़ भर सोचने वाला पहले गिरता है। Alignment न मान पढ़ें-लिखें तो ERROR_INVALID_PARAMETER (87) से fail। मानने योग्य तीन बिंदु।³

तीसरा खास कर छूटता है। malloc या new, C# array लौटा address sector boundary alignment guarantee नहीं रखते। Page boundary पर allocate VirtualAlloc use करें तो physical sector 4096 byte «Advanced Format» disk requirement भी साथ पूरी। न्यूनतम रूप इस प्रकार।

// C++ / Win32. Error handling न्यूनतम रखा है
DWORD sectorsPerCluster = 0, bytesPerSector = 0, freeClusters = 0, totalClusters = 0;
if (!GetDiskFreeSpaceW(L"C:\\", &sectorsPerCluster, &bytesPerSector,
                       &freeClusters, &totalClusters))
{
    return GetLastError();
}

// Read-write की इकाई sector size का exact multiple करना (यहाँ 1MiB के बराबर)
const DWORD chunk = (1024 * 1024 / bytesPerSector) * bytesPerSector;

// Buffer page boundary पर aligned क्षेत्र लेना (malloc/new guarantee नहीं रखते)
BYTE* buffer = static_cast<BYTE*>(
    VirtualAlloc(nullptr, chunk, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE));
if (buffer == nullptr) { return GetLastError(); }

HANDLE h = CreateFileW(L"C:\\temp\\big.bin", GENERIC_READ, FILE_SHARE_READ, nullptr,
                       OPEN_EXISTING, FILE_FLAG_NO_BUFFERING, nullptr);
if (h == INVALID_HANDLE_VALUE)
{
    // GetLastError «ठीक पहले के Win32 call» का result return करता है। पहले VirtualFree
    // बुलाने पर CreateFileW की failure का कारण (access denied · path नहीं आदि)
    // cleanup के result से overwrite हो जाता है, कारण न समझ आने वाला code ही return होता है
    const DWORD err = GetLastError();
    VirtualFree(buffer, 0, MEM_RELEASE);
    return err;
}

// हर बार chunk byte इकाई से आगे बढ़ने से size भी offset भी aligned रहते हैं
DWORD read = 0;
while (ReadFile(h, buffer, chunk, &read, nullptr) && read > 0)
{
    // buffer के आरंभ के read byte process करें
    // (file अंत पर read < chunk होता है। यह normal)
}

CloseHandle(h);
VirtualFree(buffer, 0, MEM_RELEASE);

साथ .NET FileOptions में FILE_FLAG_NO_BUFFERING अनुरूप मान नहीं। सच में चाहिए तो CreateFile सीधे बुलाना पड़ता है, तब भी ऊपर alignment requirement स्वयं माननी पड़ती है। «तेज़ चाहिए इसलिए NO_BUFFERING» नहीं, «स्वयं buffer management इसलिए NO_BUFFERING» क्रम से सोचें।

5.4. चुनाव व्यवस्थित

flowchart TB
    A["App का buffer"]
    B["System file cache<br/>(Dirty page)"]
    C["Disk device भीतर का cache"]
    D[("Volatile न रहने वाला माध्यम")]
    A -->|"Default WriteFile: यहाँ तक success return होती है"| B
    B -->|"lazy writer (हर सेकंड) / WRITE_THROUGH (तुरंत)"| C
    C -->|"Device समय /<br/>FlushFileBuffers लिख डालने की माँग"| D
    A -.->|"NO_BUFFERING cache छोड़ सीधे"| C

चित्र 5: Data की परतें और प्रत्येक tool कितना आगे धकेलता है। «Disk device भीतर का cache» अंतिम चरण भी ध्यान दें

चुनने का क्रम «बिजली कटने पर कितने records जा सकते हैं» पहले तय, फिर «उसके लिए कितना धीमा चले» पुष्टि — दो चरण। तालिका ऊपर से न देखें, यह शाखा घूमें।

flowchart TB
    S["यह data लिखने जा रहे हैं"]
    Q1{"Power loss · blue screen के क्षण<br/>जाना क्षमा है?"}
    A0["Default रहें (cache enabled)<br/>सबसे तेज़। अधिकतर I/O यहाँ"]
    Q2{"न जा सकने वाला<br/>«मोड़» है या «प्रत्येक record»?"}
    A1["मोड़ पर FlushFileBuffers<br/>.NET में Flush(true)<br/>लागत: मोड़ की wait मात्र"]
    Q3{"स्वयं buffer manage कर<br/>5.3 alignment requirement पूरी कर सकते हैं?"}
    A2["FILE_FLAG_WRITE_THROUGH<br/>लिखने हर बार तुरंत disk<br/>Read cache से तेज़ रहता है"]
    A3["FILE_FLAG_NO_BUFFERING<br/>+ FILE_FLAG_WRITE_THROUGH<br/>Official «बार-बार durability» रूप"]
    S --> Q1
    Q1 -->|"क्षमा<br/>(हाल कुछ सेकंड का log आदि)"| A0
    Q1 -->|"क्षमा नहीं"| Q2
    Q2 -->|"मोड़<br/>(Transaction निश्चित आदि)"| A1
    Q2 -->|"प्रत्येक record"| Q3
    Q3 -->|"नहीं (सामान्य app)"| A2
    Q3 -->|"हाँ (DB engine आदि)"| A3

चित्र 6: Tool चुनाव। पहला शाखा reliability माँग, दूसरा चुकाई जा सकने वाली लागत। «प्रत्येक record पर FlushFileBuffers» path नहीं, अध्याय 5.1 के अनुसार official documentation उसे inefficient मानता है

Practical pattern तीन ही गिनाते हैं।

1. «Temporary file पर लिखें → flush → नाम बदलें» अधूरी file न छोड़ने का नियम। Content लिख डालकर नाम से निश्चित — यह atomic सौंपना «File integration के exclusive control की मूल बात» में विस्तार से।
2. Database पर छोड़ना भी अच्छा design है। SQLite WAL और flush से durability बनाता है — «C# से SQLite business apps में» देखें। «स्वयं flush strategy न लिखें» विकल्प हमेशा मेज पर है।
3. Benchmark पर cache संदेह करें। «पढ़ना बहुत तेज़» माप प्रायः दूसरी बार बाद cache hit मापता है। माप रीति «Windows पर program version-दर गति सही तुलना» में है।

चित्र 5 का अंतिम चरण — disk device भीतर का cache भी न भूलें। FlushFileBuffers वहाँ तक लिख डालने की माँग करता है, पर USB या external disk पर device पक्ष लिखने का cache policy («Quick removal» बनाम «Better performance») जुड़ती है। Removable device व्यवहार «Windows apps में USB devices» भी देखें।

6. Memory-mapped file से coherency

भाग 1 में «cache का पदार्थ file mapping» सुनकर यह सोचा होगा — तो स्वयं MapViewOfFile किया view और ReadFile/WriteFile का cache लड़ते हैं?

नहीं। उसी mechanism पर बैठे हैं। File mapping object file पर आधारित, page निकालना file पर लिखने के रूप में होता है। उसी local file पर कई processes view बनाएँ तो भी दिखने वाली content coherent है।⁴

flowchart TB
    subgraph P1["Process A का address space"]
        V1["MapViewOfFile view"]
    end
    subgraph SYS["System address space"]
        SC["Cache Manager का view<br/>(ReadFile/WriteFile use slot)"]
    end
    PAGES["वही physical page समूह<br/>(File पर आधारित memory)"]
    DISK[("Disk पर file")]
    V1 --> PAGES
    SC --> PAGES
    PAGES --> DISK
    NB["FILE_FLAG_NO_BUFFERING का I/O<br/>इस share के बाहर (सीधे disk)"]
    NB -.-> DISK

चित्र 7: Map view भी cache भी उसी «file पर आधारित page» देखते हैं। बाहर केवल NO_BUFFERING

दो सावधानियाँ।

• FILE_FLAG_NO_BUFFERING I/O इस coherency के बाहर है। Cache बिना read-write और map view/cache content नहीं मिलाए जाते। मिलाएँ तो स्वयं coherency बनाएँ।
• Map view durability दो चरण है। FlushViewOfFile दायरे के dirty pages लिखना शुरू करता है, पर metadata नहीं लिखता, disk device cache से physical लिखना भी wait नहीं करता। पक्का पहुँचाने को FlushViewOfFile बाद FlushFileBuffers बुलाएँ।⁵

Shared memory के रूप में file mapping व्यवहार (named share, synchronization, typical failure patterns) «Shared memory के जाल और practical best practices» में है।

7. Fast I/O — भाग 1 homework समेटना

पहले दो पंक्ति। Fast I/O cache पर file के sync read-write के लिए बना shortcut है, IRP (I/O Request Packet। Kernel driver को सौंपने वाला request पात्र) बिना cache से सीधे data आदान-प्रदान करता है। Procmon Operation स्तंभ में IRP_MJ_READ और FASTIO_READ मिले इसलिए कि वही «पढ़ना» सामान्य path और shortcut दोनों से जा सकता है।

भाग 1 अध्याय 5.2 में «सब I/O IRP नहीं बनता» लिखा। उत्तर मिलान।

Cache पर file का read-write IRP बना device stack बहाए बिना cache से memory copy से complete जाना जाता है। इसलिए Windows cache वाली file के sync I/O के लिए fast I/O shortcut देता है — IRP न बना, file system «fast I/O entry point» सीधे बुला, Cache Manager से सीधे copy।⁶ Fast I/O न सँभाले (cache पर नहीं, lock जुड़ा, filter बीच में आदि) तो सामान्य IRP path पर लौटता है। यह sync request का तेज़ path है, «cache hit = हमेशा fast I/O» नहीं। Async (FILE_FLAG_OVERLAPPED) handle operation cache से वहीं complete होने पर भी (भाग 2 अध्याय 5) IRP path से processed हो सकता है।

flowchart TB
    REQ["Cache-enabled handle पर sync read-write"]
    Q{"Fast I/O से process हो सकता है?<br/>(Cache पर है आदि)"}
    FAST["Fast I/O<br/>IRP बिना cache से सीधे copy<br/>Procmon पर FASTIO_ दिखता है"]
    IRP["सामान्य path<br/>IRP बना device stack<br/>(भाग 1 चित्र 6 की दुनिया)"]
    REQ --> Q
    Q -->|हाँ| FAST
    Q -->|नहीं| IRP

चित्र 8: Fast I/O शाखा। Procmon पर FASTIO_READ और IRP_MJ_READ मिलने का यही कारण

भाग 1 अध्याय 7 Procmon observation में FASTIO_ पंक्तियाँ मिली थीं, अब समझाया जा सकता है। Cache hit read IRP भी विलास है। यह path भाग 6 filter drivers पर भी प्रभाव डालता है (minifilters fast I/O पर भी बीच में आ सकते हैं)।

8. सारांश

• Windows file cache write-back, पदार्थ file 256KB खंड mapping। Cache-enabled read-write slot से memory copy।¹
• Read read-ahead सट्टा लगाता है, SequentialScan/RandomAccess उसके hints।¹
• Write हर सेकंड lazy writer पीछे करता है। App मरे data बचता है, OS सहित मरे dirty भाग जाता है। Design का प्रश्न «यह data बिजली कटने के क्षण जा सकता है?»।¹
• पक्का लिखने के tools FlushFileBuffers (मोड़ पर निश्चित) / WRITE_THROUGH (लिखने हर बार) / NO_BUFFERING (cache बिना + alignment requirement)। हर बार flush inefficient, बार-बार durability पर NO_BUFFERING+WRITE_THROUGH साथ official recommendation। Metadata हमेशा cache — यह भी ध्यान।²³¹
• Map view और cache वही pages share coherent। बाहर केवल NO_BUFFERING। Map durability FlushViewOfFile+FlushFileBuffers दो चरण।⁴⁵
• Cache hit sync read-write fast I/O से IRP भी छोड़ता है। भाग 1 Procmon FASTIO_ का असली रूप।⁶

आगे भाग 5 «NTFS internals — MFT से समझा file system»। अब तक file «offset और byte sequence» थी, पीछे NTFS data कैसे रखता है — MFT, कई data streams, journal, hard links — disk पर static structure की ओर उतरते हैं।

संबंधित articles

• Windows I/O की गहराई (भाग 1) — सब read-write IRP बनता है: I/O system का पूरा चित्र
• Windows I/O की गहराई (भाग 2) — Sync I/O और async I/O: OVERLAPPED का असली अर्थ
• Windows I/O की गहराई (भाग 3) — I/O completion port (IOCP) और .NET thread pool: async/await का तहखाना
• File integration के exclusive control की मूल बात — file lock और atomic claim best practices
• Shared memory के जाल और practical best practices
• C# से SQLite business apps में — WAL mode, exclusive control, corruption रोक, EF Core चुनाव
• Windows पर program version-दर गति सही तुलना
• Windows apps में USB devices — virtual COM, HID, WinUSB, dedicated SDK चुनाव

संबंधित consulting क्षेत्र

KomuraSoft LLC «save किया data गया», «file लिखना धीमा / बहुत तेज़ संदेह» जैसे Windows business apps file I/O design और troubleshooting सँभालता है।

• Windows app development
• Bugs की जाँच और root-cause analysis
• मौजूदा assets का reuse और migration
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

WriteFile success return करे तो data disk पर लिखा जा चुका है?

Default से नहीं। Windows file cache write-back तरीके से काम करता है, WriteFile data system file cache में copy होते ही success return करता है। Disk पर लिखना Cache Manager हर सेकंड चला lazy writer बाद में करता है। महत्त्वपूर्ण typical failure types से अंतर। App process crash हो तो cache में गया data OS जीवित रहे बाद लिखा जाता है, नहीं जाता। दूसरी ओर OS सहित गिरे (power loss, blue screen) तो अभी न लिखा dirty cache जाता है। «WriteFile सफल = durable» नहीं, «सफल = OS को सौंपा» सटीक समझ है।

पक्का disk पर लिखने के लिए क्या करें?

तीन tools। पहला FlushFileBuffers, उस file का buffered data और metadata device तक लिख देता है (.NET में FileStream.Flush(true) इसके बराबर)। दूसरा FILE_FLAG_WRITE_THROUGH, लिखने हर बार cache पर लिखते तुरंत disk पर भी। तीसरा FILE_FLAG_NO_BUFFERING, cache स्वयं से नहीं गुज़रता। Microsoft documentation लिखने हर बार FlushFileBuffers बुलाना inefficient मानता है, बार-बार लिखने पर पक्की durability चाहिए तो FILE_FLAG_NO_BUFFERING और FILE_FLAG_WRITE_THROUGH साथ use कहता है। सब cache फ़ायदा छोड़ते धीमे होते हैं, इसलिए «सब पर लगाएँ» नहीं, न खो सकने वाले data लिखने तक सीमित रखना practical कुंजी है।

FILE_FLAG_WRITE_THROUGH और FILE_FLAG_NO_BUFFERING में क्या अंतर है?

WRITE_THROUGH «cache पर लिखें, complete होने से पहले disk पर भी लिखें»। Read cache फ़ायदा लेता रहता है, lazy writing की delay मात्र हटती है। NO_BUFFERING «read-write system cache से नहीं गुज़रता», read और write हर बार disk device I/O (पर छोड़ता Windows cache तक, device भीतर लिखने का cache नहीं)। उसके बदले सख्त constraint: read-write का size और file offset volume sector size का exact multiple, buffer address भी physical sector boundary पर aligned। साथ NO_BUFFERING पर भी file system metadata cache होता रहता है, metadata तक पक्का लिखने को FlushFileBuffers या WRITE_THROUGH साथ चाहिए। Database engine जैसे स्वयं buffer management करने वाला software प्रतिनिधि; सामान्य apps पहले WRITE_THROUGH या FlushFileBuffers सोचें।

Task Manager पर free memory कम दिखे तो file cache कारण है?

अधिकतर हाँ, और यह normal व्यवहार है। Windows free physical memory को active file cache के रूप में use करता है, बड़ी file copy या बहुत read-write करें तो cache फूल memory usage बढ़ा दिखता है। पर cache use pages अधिकतर app memory माँगे तो अपेक्षाकृत जल्दी सौंपे जाने वाले प्रकार के हैं, «memory खाकर कमी» अवस्था से अलग जाँचें। Memory shortage संदेह पर दिखा free मात्रा भर नहीं, committed memory या hard fault frequency जैसे indicators देखना practical है।

Memory-mapped file और ReadFile/WriteFile से वही file छुएँ तो content बिखरती है?

सामान्य cache-enabled I/O के बीच नहीं। Windows cache स्वयं file mapping से लागू, उसी local file पर map view और cache वही data share करते हैं, एक का बदलाव दूसरे से दिखता है। कई processes उसी file mapping object से view बनाएँ तो data coherent रहता है। पर FILE_FLAG_NO_BUFFERING से खुले handle का read-write cache से नहीं गुज़रता, इस coherency के बाहर। Map view बदलाव पक्का disk पर लिखने को FlushViewOfFile अकेले metadata नहीं लिखता और hardware cache भी नहीं wait करता, इसलिए FlushViewOfFile बाद FlushFileBuffers बुलाना पड़ता है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।