מעמקי הקלט/פלט ב-Windows (פרק 4) — מנהל המטמון: מתי ה-WriteFile שלכם מגיע לדיסק

WriteFile החזיר הצלחה. ובכן, איפה הנתונים עכשיו?

התשובה, כמעט בוודאות, היא שעדיין אינם בדיסק. הם רק הועתקו למטמון בזיכרון. לכן קורה «שמרתי, ואחרי הפסקת חשמל זה נעלם»; לכן מדדי העתקת קבצים מציגים מהירויות שאינן אפשריות פיזית; ולכן מסדי נתונים קוראים באדיקות ל-fsync.

פרק 4 בסדרה «מעמקי הקלט/פלט ב-Windows» עוסק במה שעומד באמצע: מנהל המטמון. בפרק 2 כתבנו ש«אם הנתונים כבר במטמון, גם קלט/פלט אסינכרוני מסתיים באופן סינכרוני», ובפרק 1 השארנו כשיעורי בית את «הדרך הקצרה שאינה בונה IRP — Fast I/O». הפעם נסגור את שני החוטים האלה.

1. השורה התחתונה קודם

• מטמון הקבצים של Windows הוא מטמון write-back. קריאה באה קודם ממטמון הקבצים של המערכת, וגם כתיבה הולכת קודם למטמון. ההשתקפות לדיסק נעשית אחר כך בידי מערכת ההפעלה.¹
• הזהות האמיתית של המטמון היא מיפוי קובץ. מנהל המטמון ממפה מקטעים של 256KB מהקובץ למרחב הכתובות של המערכת, והקריאה והכתיבה הופכות ל«העתקת זיכרון מול התצוגה הזו» (פרק 2).¹
• את הכתיבה מדביק lazy writer שרץ כל שנייה. קריסת יישום אינה מאבדת נתונים, אבל הפסקת חשמל או קריסת מערכת ההפעלה מאבדות מטמון מלוכלך שעדיין לא נכתב (פרק 4).¹
• יש שלושה כלים ל«לכתוב בוודאות». FlushFileBuffers (= Flush(true) ב-.NET), FILE_FLAG_WRITE_THROUGH, ו-FILE_FLAG_NO_BUFFERING. שטיפה בכל כתיבה תכופה אינה יעילה, והתיעוד הרשמי מציין שילוב של NO_BUFFERING+WRITE_THROUGH (פרק 5).²¹
• ל-NO_BUFFERING יש דרישות יישור. גודל והיסט חייבים להיות כפולה שלמה של גודל המגזר, וגם כתובת המאגר מיושרת לגבול מגזר פיזי. וגם עם NO_BUFFERING מטא-נתונים ממשיכים להיות במטמון (סעיף 5.3).³¹
• תצוגה ממופה והמטמון חולקים את אותם נתונים. קובץ ממופה לזיכרון וקלט/פלט מטמון רגיל עקביים, והפיכת מיפוי לעמיד היא שני שלבים: FlushViewOfFile+FlushFileBuffers (פרק 6).⁴⁵
• קריאה וכתיבה סינכרוניות שעלו למטמון לפעמים אינן בונות אפילו IRP. דרך קצרה בשם Fast I/O הולכת ישר למנהל המטמון — זו התשובה לשיעורי הבית מפרק 1 (פרק 7).⁶

מפת הידע של המאמר

הצלחת WriteFile אינה משמעותה התמדה בדיסק: מטמון הקבצים של Windows מעתיק תחילה לתצוגת מטמון המערכת, ואת ההשתקפות לדיסק רודף lazy writer בכל שנייה. בניתוק חשמל או בקריסת מערכת הפעלה אובדים דפים מלוכלכים שטרם נכתבו, ולכן לנתונים שרוצים לכתוב בוודאות יש לבחור בין FlushFileBuffers, ‏FILE_FLAG_WRITE_THROUGH ו-FILE_FLAG_NO_BUFFERING.

flowchart LR
    accTitle: מפת הידע של מנהל המטמון ושל כתיבה מושהית
    accDescr: תרשים שמראה את הקשרים בין מנהל המטמון, מטמון כתיבה לאחור, תצוגת מטמון המערכת של 256KB, קריאה מראש, כתיבה מושהית של lazy writer, אובדן דפים מלוכלכים בניתוק חשמל, כתיבה ודאית באמצעות FlushFileBuffers, ‏FILE_FLAG_WRITE_THROUGH ו-FILE_FLAG_NO_BUFFERING, דרישות יישור, עקביות עם מיפוי קובץ לזיכרון, ו-Fast I/O
    cache_manager["מנהל המטמון"]
    write_behind_caching["מטמון כתיבה לאחור (שיטת כתיבה מושהית)"]
    memory_mapped_file["מיפוי קובץ לזיכרון (memory-mapped file)"]
    system_cache_view["תצוגת מטמון המערכת (חריץ 256KB)"]
    file_object["אובייקט קובץ"]
    lazy_writer["lazy writer (ת'רד כתיבה מושהית)"]
    unflushed_write_loss["אובדן נתונים שטרם נכתבו לדיסק"]
    temp_file_attribute["FILE_ATTRIBUTE_TEMPORARY"]
    dirty_page["דף מלוכלך (dirty page)"]
    power_loss["ניתוק חשמל או קריסת מערכת הפעלה"]
    read_ahead["קריאה מראש (read-ahead)"]
    sequential_scan_hint["FILE_FLAG_SEQUENTIAL_SCAN"]
    random_access_hint["FILE_FLAG_RANDOM_ACCESS"]
    flushfilebuffers["FlushFileBuffers"]
    write_through["FILE_FLAG_WRITE_THROUGH"]
    no_buffering["FILE_FLAG_NO_BUFFERING"]
    sector_alignment_requirement["דרישת יישור למגזר"]
    invalid_parameter_error["ERROR_INVALID_PARAMETER(87)"]
    frequent_durable_write["התמדה ודאית בכתיבות תכופות"]
    flushviewoffile["FlushViewOfFile"]
    fast_io["Fast I/O"]
    procmon["Process Monitor(procmon.exe)"]
    irp["IRP (חבילת בקשת קלט/פלט)"]
    synchronous_io["קלט/פלט סינכרוני"]
    cache_manager -->|"מממש את"| write_behind_caching
    write_behind_caching -->|"משתמש ב"| memory_mapped_file
    cache_manager -->|"משתמש ב"| system_cache_view
    system_cache_view -->|"משתמש ב"| memory_mapped_file
    cache_manager -->|"משתמש ב"| file_object
    cache_manager -->|"משתמש ב"| lazy_writer
    lazy_writer -->|"מאוטמט את"| write_behind_caching
    lazy_writer -->|"מצמצם"| unflushed_write_loss
    temp_file_attribute -.->|"אינו מתיישב עם"| lazy_writer
    write_behind_caching -->|"עלול לגרום ל"| dirty_page
    dirty_page -->|"נשמר ב"| system_cache_view
    power_loss -.->|"עלול לגרום ל"| unflushed_write_loss
    cache_manager -.->|"מונע"| unflushed_write_loss
    cache_manager -->|"משתמש ב"| read_ahead
    read_ahead -.->|"מוגדר באמצעות"| sequential_scan_hint
    read_ahead -.->|"מוגדר באמצעות"| random_access_hint
    flushfilebuffers -->|"מונע"| unflushed_write_loss
    write_through -->|"מונע"| unflushed_write_loss
    no_buffering -.->|"מצמצם"| unflushed_write_loss
    no_buffering -->|"מחייב"| sector_alignment_requirement
    sector_alignment_requirement -->|"מונע"| invalid_parameter_error
    no_buffering -->|"עלול לגרום ל"| invalid_parameter_error
    flushfilebuffers -->|"שימוש לא מומלץ ל"| frequent_durable_write
    no_buffering -->|"מענה מומלץ ל"| frequent_durable_write
    write_through -->|"מענה מומלץ ל"| frequent_durable_write
    no_buffering -->|"אינו מתיישב עם"| system_cache_view
    flushviewoffile -->|"מחייב"| memory_mapped_file
    flushviewoffile -->|"צריך לקדום ל"| flushfilebuffers
    fast_io -->|"נבדק באמצעות"| procmon
    fast_io -->|"מחייב"| system_cache_view
    fast_io -->|"אינו מתיישב עם"| irp
    fast_io -->|"מחייב"| synchronous_io

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 32, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

2. הזהות האמיתית של המטמון — הקובץ ממופה לזיכרון

2.1. משבצות של 256KB והעתקת זיכרון

אם חושבים על מטמון הקבצים של Windows כ«מיכל של בלוקי דיסק», הרבה מההתנהגות מפסיקה להיות ניתנת להסבר. התמונה הנכונה היא זו: מנהל המטמון ממפה מקטעים של 256KB מהקובץ ל«משבצות» במרחב הכתובות של המערכת, וקריאה וכתיבה עם מטמון מופעל מבוצעות כהעתקת זיכרון בין המשבצת הזו לבין המאגר של היישום.¹

flowchart TB
    subgraph U["היישום（מצב משתמש）"]
        BUF["המאגר של היישום<br/>（האזור שהועבר ל-ReadFile/WriteFile）"]
    end
    subgraph S["מרחב הכתובות של המערכת"]
        SLOT["מטמון הקבצים של המערכת<br/>משבצת שממפה מקטע של 256KB מהקובץ"]
    end
    DISK[("הקובץ בדיסק")]
    BUF <-->|"ReadFile/WriteFile =<br/>העתקת זיכרון מול המשבצת"| SLOT
    SLOT <-->|"קריאה בגישה הראשונה ו<br/>כתיבה לאחור מאוחרת לפי דפים"| DISK

איור 1: התמונה האמיתית של קלט/פלט עם מטמון מופעל. «קריאה וכתיבה של קובץ» מנקודת מבט היישום הן, ברוב המקרים, רק העתקת זיכרון

נקודה אחת שקל לטעות בה. 256KB הוא יחידת החלוקה של התצוגה (המיפוי), ולא טענה שקלט/פלט לדיסק תמיד מתבצע ביחידות של 256KB. דפים בתוך משבצת נקראים לפי הצורך, וכמות הקלט/פלט שבאמת עפה לדיסק משתנה לפי גודל הבקשה ודפוס הגישה. אם זה מקטע שנקרא בפעם הראשונה, מתרחש קלט/פלט לדיסק כדי למלא אותו (כאן IRP מפרק 1 יורד למחסנית האחסון התחתונה). אם כבר במטמון, הקריאה מסתיימת בהעתקה בלבד. מה שראינו בפרק 2, סעיף 5 — «פגיעה במטמון משלימה באופן סינכרוני גם כשהונפקה באופן אסינכרוני» — הוא ביטוי של התנועה הזו, «בקשה שאפשר לענות עליה מיד משלימים במקום». ולהפך, כשהמטמון מופעל אבל הדף אינו בזיכרון, לטיפול ב-page fault אין מנגנון אסינכרוני, ולכן קריאה אסינכרונית עלולה להיות מעובדת באופן סינכרוני — מלכודת שגם אותה ראינו בפרק 2.⁷

2.2. הזהות האמיתית של «הזיכרון הפנוי קטן»

האם משתמשים במטמון ומצב הקריאה מראש מנוהלים לפי אופן הפתיחה (ליחידת אובייקט קובץ),¹ אבל גוף הנתונים שבמטמון משותף לפי קובץ (זרם). כמה פעמים שלא תפתחו את אותו קובץ, לא נוצרים מטמונים נפרדים — מכל handle נראה אותו תוכן מטמון (זה הבסיס לעקביות בפרק 6). המטמון פועל תחת פיקוד מנהל המטמון כל עוד Windows רצה.¹ אם מעתיקים קובץ גדול או קוראים וכותבים בהיקף גדול, זיכרון פיזי פנוי מוסב יותר ויותר למטמון. גם כשבמנהל המשימות הזיכרון הפנוי נראה קטן, רובו הוא «זיכרון בהמתנה שמשמש שימוש בעל ערך, ויימסר במהירות ברגע שיישום יבקש אותו». כדי לא לטעות בהבחנה הזו באבחון מחסור בזיכרון, פרקטיקת התצפית טופלה גם ב«להבחין בין עיכוב GC לדליפת זיכרון ב-.NET».

אפשר לאשר את התנועה הזו על המסך. פותחים מנהל המשימות > ביצועים > זיכרון, וסרגל «הרכב הזיכרון» בתחתית מחולק לבשימוש / שונה / בהמתנה / פנוי. רוב מטמון הקבצים נכנס לבהמתנה הזו, וברשימה מימין מסוכם כ«במטמון». לפירוט דק יותר, צג המשאבים > לשונית זיכרון מציג את אותן קטגוריות עם נפחים. מעתיקים קובץ אחד של כמה ג’יגה-בתים ומסתכלים שוב: ההמתנה גדלה והפנוי קטן, אבל «בשימוש» כמעט אינו משתנה — כלומר לא «הזיכרון נאכל» אלא «זיכרון שהיה פנוי הוסב למטמון», וזה נראה בעין.

3. קריאה מראש — ספקולציה על קריאה

מנהל המטמון, לפי דפוסי גישה מהעבר, קורא מראש את המקטע שכנראה ייקרא הבא (read-ahead). לקובץ שנקרא לפי הסדר, נתוני ההמשך כבר יושבים במטמון לפני שהיישום ביקש — זה פירוק הקסם של מהירות קריאה רציפה. כמות הקריאה מראש אינה קבועה; היא משתנה לפי הדפוס שזוהה וגודל הבקשה.

flowchart LR
    A["היסטוריית בקשות הקריאה של היישום<br/>קורא מההתחלה לפי הסדר"]
    D{"מנהל המטמון<br/>מזהה את הדפוס"}
    R["קריאה מראש: מקטע ההמשך<br/>נקרא לפני שמבקשים אותו<br/>（הכמות משתנה לפי דפוס וגודל בקשה）"]
    H1["רמז FILE_FLAG_SEQUENTIAL_SCAN<br/>= קריאה מראש באופן פעיל"]
    H2["רמז FILE_FLAG_RANDOM_ACCESS<br/>= קריאה מראש תתבזבז ולכן מדכאים"]
    A --> D
    D --> R
    H1 -.-> D
    H2 -.-> D

איור 2: קריאה מראש. מלבד זיהוי דפוס הגישה, אפשר לתת רמז בדגלי CreateFile

FileOptions.SequentialScan / RandomAccess מטבלת ההתאמה בפרק 1 הם רמזים למנוע הקריאה מראש הזה. לעיבוד אצווה ש«מלקק הכול לפי הסדר» — הראשון; לגישה שמדלגת כמו מעבר על אינדקס — השני. חושבים עליהם כדגלים שבהם היישום מספר למערכת ההפעלה על עתיד שרק הוא יודע, והמקום להשתמש בהם מתבהר.

4. כתיבה מאוחרת — המשמעות של «הצלחה» של WriteFile

4.1. lazy writer מגיע כל שנייה

בצד הכתיבה זה מטמון write-back. WriteFile מחזיר הצלחה ברגע שהנתונים הועתקו למשבצת, וההשתקפות לדיסק נדחית. מדיניות «לכתוב באיחור» הזו היא כתיבה מאוחרת (lazy writing).¹

את ההשתקפות נושא lazy writer, שמנהל המטמון מפעיל כל שנייה. הוא שם בתור שמינית מהדפים שלא נשטפו לאחרונה וכותב אותם, ואם יש עוד הרבה לכתוב הוא מוסיף עוד. קבצים זמניים שנוצרו עם המאפיין FILE_ATTRIBUTE_TEMPORARY אינם יעד לשטיפה של lazy writer — אין טעם לכתוב משהו שצפוי להימחק מיד.¹ אבל זה רמז לפי מאפיין: אם הזיכרון לוחץ עדיין אפשר לכתוב בחזרה, ועל קובץ ש«רק השם נשמע זמני» זה אינו חל.

sequenceDiagram
    participant App as יישום
    participant C as מטמון המערכת
    participant LW as lazy writer（מופעל כל שנייה）
    participant D as דיסק

    App->>C: WriteFile(נתונים)
    Note over C: מעתיק למשבצת<br/>ומסמן את הדף כמלוכלך（עדיין לא נכתב）
    C-->>App: TRUE חוזר מיד
    Note over App,C: מכאן עד הכתיבה לאחור זה «חלון מסוכן»<br/>בהפסקת חשמל או קריסת מערכת ההפעלה הנתונים האלה ייעלמו
    LW->>C: בוחר 1/8 מהדפים המלוכלכים
    LW->>D: כותב אותם בחזרה בבת אחת
    Note over D: רק כאן זה הופך לעמיד

איור 3: כתיבה מאוחרת. הצלחת WriteFile היא «נמסר למערכת ההפעלה», לא «נעשה עמיד»

4.2. מה קרה, ועד כמה נעלם

נדייק את משמעות «החלון המסוכן». הגורל מתפצל לפי סוג הכשל.

flowchart TB
    W["הנתונים מיד אחרי הצלחת WriteFile<br/>（דף מלוכלך במטמון）"]
    Q{"מה קרה"}
    A1["תהליך היישום<br/>קרס / הסתיים בכפייה"]
    A2["מערכת ההפעלה כולה נעצרה<br/>（הפסקת חשמל · מסך כחול）"]
    S["הנתונים נשארים<br/>המטמון שייך למערכת ההפעלה ולכן<br/>lazy writer כותב בחזרה כמתוכנן"]
    L["דפים מלוכלכים אובדים<br/>נשאר רק מה שכבר הגיע לדיסק"]
    W --> Q
    Q --> A1
    Q --> A2
    A1 --> S
    A2 --> L

איור 4: סוג הכשל וקו פרשת המים של הישרדות. המטמון אינו «רכוש התהליך» אלא «רכוש מערכת ההפעלה»

• גם אם היישום מת, הנתונים אינם נעלמים. מרגע שההעתקה למטמון הסתיימה, בעל הנתונים הוא מערכת ההפעלה. «שמרנו והיישום נפל מיד, והקובץ נשאר שלם» קורה בזכות זה.
• אם מערכת ההפעלה כולה מתה, החלק המלוכלך נעלם. תדירות השטיפה מכוונת כפשרה בין ביצועים לאמינות, והתיעוד מציין במפורש ש«אם מתרחש אובדן פתאומי של חשמל, נתונים שבמטמון אובדים».¹

כלומר השאלה בתכנון יישום עסקי היא: «האם מותר לנתונים האלה להיאבד ברגע של הפסקת חשמל?» כמה שניות של יומן אולי מותר. רשומת הזמנה מאושרת — כנראה אסור. רק על מה שאסור להפסיד משתמשים בכלים בפרק הבא.

5. ארגז הכלים ל«נכתב בוודאות»

5.1. FlushFileBuffers — לכתוב עד הסוף עכשיו

FlushFileBuffers כותב עד הסוף אל ההתקן את הנתונים שנאגרו לקובץ שצוין. מטא-נתונים של מערכת הקבצים תמיד במטמון, ולכן כדי להגיע בוודאות גם למטא-נתונים נדרשת שטיפה (או WRITE_THROUGH) — גם זו נקודה לאחוז בה.¹² ב-.NET המקבילה היא FileStream.Flush(true) (Flush() לבדו רק מוסר את המאגר הפנימי של .NET למערכת ההפעלה, ומטמון מערכת ההפעלה נשאר כפי שהוא).⁸

אבל התיעוד הרשמי נועץ מסמר במפורש — לקרוא בכל כתיבה אינו יעיל. אם נדרשת עמידות בכל אחת מתוך כתיבות רבות, יש להשתמש ב-NO_BUFFERING+WRITE_THROUGH שלהלן.²

5.2. FILE_FLAG_WRITE_THROUGH — להסיר רק את העיכוב

כשפותחים עם FILE_FLAG_WRITE_THROUGH, הכתיבה נכתבת גם למטמון, וגם מיד לדיסק בלי לחכות ל-lazy writer.¹ הנקודה היא שקריאות ממשיכות ליהנות מהמטמון — תשובה ישרה ל«הקריאה תישאר מהירה, רק עיכוב הכתיבה יוסר».

5.3. FILE_FLAG_NO_BUFFERING — בלי לעבור במטמון

FILE_FLAG_NO_BUFFERING מוציא את מטמון המערכת עצמו מקריאה וכתיבה. כל קריאה וכתיבה הופכות לקלט/פלט אל התקן הדיסק, בלי לעבור במטמון.¹ אבל מה שאפשר לעקוף הוא רק את מטמון המערכת של Windows; כפי שרואים באיור 5, מטמון הכתיבה בתוך ההתקן הוא קומה נפרדת. אם דרושה גם עמידות להפסקת חשמל, עדיין נדרשים שילוב עם WRITE_THROUGH או FlushFileBuffers. זה כלי להעברה המונית של נפח גדול, או למנוע מסד נתונים שמנהל מאגרים בעצמו — אבל מצורף חוזה קשיח.³

• הגודל והיסט הקובץ של קריאה וכתיבה הם כפולה שלמה של גודל המגזר של הכרך (למגזר 512 בתים: 512, 1024, 1536…).
• גם כתובת המאגר מיושרת לגודל המגזר הפיזי (נדרשת גם התחשבות בדיסקי «Advanced Format» עם מגזר פיזי של 4096 בתים).
• ועדיין מטא-נתונים ממשיכים להיות במטמון, ולכן לעמידות מלאה נדרשים שילוב עם WRITE_THROUGH או FlushFileBuffers.¹²

«החוזה» הזה הוא המקום הראשון שבו נופלים מי שחשבו שמספיק להוסיף דגל. קריאה וכתיבה בלי לשמור על יישור נכשלות ב-ERROR_INVALID_PARAMETER (87). נסדר את שלוש הנקודות שצריך לקיים.³

את השלישית הכי קל לפספס. לכתובת שמחזירים malloc, new או מערך C# אין הבטחת יישור לגבול מגזר. VirtualAlloc, שמקצה לפי גבול דף, ממלא בדרך גם את דרישת דיסקי «Advanced Format» עם מגזר פיזי של 4096 בתים. הצורה המינימלית נראית כך.

// C++ / Win32. טיפול השגיאות מצומצם למינימום.
DWORD sectorsPerCluster = 0, bytesPerSector = 0, freeClusters = 0, totalClusters = 0;
if (!GetDiskFreeSpaceW(L"C:\\", &sectorsPerCluster, &bytesPerSector,
                       &freeClusters, &totalClusters))
{
    return GetLastError();
}

// יחידת הקריאה/כתיבה כפולה שלמה של גודל המגזר (כאן בערך 1MiB)
const DWORD chunk = (1024 * 1024 / bytesPerSector) * bytesPerSector;

// המאגר הוא אזור מיושר לגבול דף (malloc/new אינם מבטיחים זאת)
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 האחרונה». אם קוראים קודם
    // ל-VirtualFree, סיבת הכשל של CreateFileW (גישה נדחתה, נתיב חסר וכו')
    // נדרסת בתוצאת הניקוי, וחוזר רק קוד שגיאה שאי אפשר להבין ממנו את הסיבה
    const DWORD err = GetLastError();
    VirtualFree(buffer, 0, MEM_RELEASE);
    return err;
}

// מתקדמים כל פעם ביחידות של chunk בתים, ולכן גם הגודל וגם ההיסט נשארים מיושרים
DWORD read = 0;
while (ReadFile(h, buffer, chunk, &read, nullptr) && read > 0)
{
    // לעבד את read הבתים הראשונים של buffer
    // (בסוף הקובץ read < chunk. זה תקין)
}

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

ועוד: ב-FileOptions של .NET אין ערך שמקביל ל-FILE_FLAG_NO_BUFFERING. אם באמת צריך — קוראים ל-CreateFile ישירות, וגם אז צריך לקיים בעצמכם את דרישות היישור למעלה. סדר הבחינה הוא «NO_BUFFERING כי אני מנהל מאגרים בעצמי», לא «NO_BUFFERING כי אני רוצה שיהיה מהיר».

5.4. סיכום מתי להשתמש במה

flowchart TB
    A["המאגר של היישום"]
    B["מטמון הקבצים של המערכת<br/>（דפים מלוכלכים）"]
    C["המטמון בתוך התקן הדיסק"]
    D[("מצע רישום שאינו נדיף")]
    A -->|"WriteFile כברירת מחדל: הצלחה חוזרת כשמגיעים לכאן"| B
    B -->|"lazy writer（כל שנייה） / WRITE_THROUGH（מיידי）"| C
    C -->|"תזמון ההתקן /<br/>FlushFileBuffers דורש כתיבה עד הסוף"| D
    A -.->|"NO_BUFFERING מדלג על המטמון והולך ישר"| C

איור 5: שכבות הנתונים, ועד כמה כל כלי דוחף. לא לשכוח גם את הקומה האחרונה, «המטמון בתוך התקן הדיסק»

סדר הבחירה הוא שני שלבים: קודם מחליטים כמה מותר לאבד ברגע של הפסקת חשמל, ואחר כך בודקים כמה מותר להאט בשביל זה. לא להסתכל בטבלה מלמעלה למטה — ללכת לפי הפיצול הזה.

flowchart TB
    S["עומדים לכתוב את הנתונים האלה"]
    Q1{"ברגע של הפסקת חשמל או מסך כחול<br/>האם מותר שיאבדו"}
    A0["להשאיר כברירת מחדל（מטמון מופעל）<br/>הכי מהיר. כמעט כל הקלט/פלט כאן"]
    Q2{"מה שאי אפשר לאבד הוא<br/>«אבן דרך» או «כל רשומה»"}
    A1["באבן דרך FlushFileBuffers<br/>ב-.NET זה Flush(true)<br/>העלות: רק ההמתנה באבן הדרך"]
    Q3{"מנהלים מאגרים בעצמכם ו<br/>מקיימים את דרישות היישור מ-5.3"}
    A2["FILE_FLAG_WRITE_THROUGH<br/>בכל כתיבה מיד לדיסק<br/>הקריאה נשארת מהירה דרך המטמון"]
    A3["FILE_FLAG_NO_BUFFERING<br/>+ FILE_FLAG_WRITE_THROUGH<br/>צורת «עמידות תכופה» שהתיעוד הרשמי מציין"]
    S --> Q1
    Q1 -->|"מותר<br/>（יומן של השניות האחרונות וכו'）"| A0
    Q1 -->|"אסור"| Q2
    Q2 -->|"אבן דרך<br/>（אישור עסקה וכו'）"| A1
    Q2 -->|"כל רשומה"| Q3
    Q3 -->|"לא（יישום רגיל）"| A2
    Q3 -->|"כן（מנוע מסד נתונים וכו'）"| A3

איור 6: איך בוחרים כלי. הפיצול הראשון הוא דרישת האמינות, השני הוא המחיר שאפשר לשלם. אין נתיב של «FlushFileBuffers לכל רשומה», כי כפי שראינו ב-5.1 התיעוד הרשמי רואה בזה חוסר יעילות

שלושה דפוסים מעשיים שכדאי לתת להם שם.

1. «לכתוב לקובץ זמני → לשטוף → לשנות שם» הוא הכלל הקבוע שלא להשאיר קובץ שנכתב למחצה. קודם כותבים את התוכן עד הסוף, ואחר כך מאשרים בשם — המסירה האטומית הזו טופלה בפירוט ב«ידע בסיסי על בקרת הרשאות בלעדיות בהעברת קבצים».
2. להשאיר למסד הנתונים זו גם בנייה לגיטימית לגמרי. איך SQLite בונה עמידות מ-WAL ומשטיפה — ב«שימוש ב-SQLite ביישום עסקי מ-C#». האפשרות «לא לכתוב אסטרטגיית שטיפה בעצמכם» תמיד על השולחן.
3. במדד ביצועים — לחשוד במטמון. מדידה ש«הקריאה מהירה מדי» בדרך כלל תופסת פגיעה במטמון מהמעבר השני ואילך. נוהל המדידה מסודר ב«איך משווים נכון מהירות בין גרסאות תוכנה ב-Windows».

ואל תשכחו את הקומה האחרונה באיור 5 — המטמון בתוך התקן הדיסק. FlushFileBuffers דורש כתיבה עד הסוף כולל לשם, אבל בכונני USB ודיסקים חיצוניים מתערב מדיניות מטמון הכתיבה של ההתקן («הסרה מהירה» מול «ביצועים טובים יותר»). לטיפול בהתקנים נתיקים ראו גם «איך לטפל בהתקני USB מיישום Windows».

6. עקביות עם קובץ ממופה לזיכרון

בפרק 1, כששמעו ש«הזהות האמיתית של המטמון היא מיפוי קובץ», בוודאי היה מי שחשב: אז התצוגה שאני עצמי עשיתי ב-MapViewOfFile והמטמון של ReadFile/WriteFile לא רבים?

לא. כי הם יושבים על אותו מנגנון. אובייקט מיפוי קובץ נשען על קובץ, ודחיקת דף מבוצעת ככתיבה לאחור אל הקובץ. גם אם כמה תהליכים יוצרים תצוגות של אותו קובץ מקומי, התוכן שנראה קוהרנטי (עקבי).⁴

flowchart TB
    subgraph P1["מרחב הכתובות של תהליך A"]
        V1["התצוגה של MapViewOfFile"]
    end
    subgraph SYS["מרחב הכתובות של המערכת"]
        SC["התצוגה של מנהל המטמון<br/>（המשבצת שמשמשת את ReadFile/WriteFile）"]
    end
    PAGES["אותם דפים פיזיים<br/>（זיכרון הנשען על הקובץ）"]
    DISK[("הקובץ בדיסק")]
    V1 --> PAGES
    SC --> PAGES
    PAGES --> DISK
    NB["קלט/פלט עם FILE_FLAG_NO_BUFFERING<br/>מחוץ לשיתוף הזה（ישר לדיסק）"]
    NB -.-> DISK

איור 7: גם התצוגה הממופה וגם המטמון מסתכלים על אותם «דפים הנשענים על הקובץ». מחוץ למעגל נמצא רק NO_BUFFERING

שתי נקודות לתשומת לב.

• קלט/פלט עם FILE_FLAG_NO_BUFFERING מחוץ לעקביות הזו. קריאה וכתיבה שעוקפות את המטמון אינן מיושרות מול תוכן דרך תצוגה ממופה / מטמון. אם מערבבים — צריך ליישר בעצמכם.
• הפיכת תצוגה ממופה לעמידה היא שני שלבים. FlushViewOfFile מתחיל כתיבה של דפים מלוכלכים בטווח, אבל אינו כותב מטא-נתונים ואינו ממתין לכתיבה פיזית ממטמון התקן הדיסק. כדי להגיע בוודאות, אחרי FlushViewOfFile קוראים ל-FlushFileBuffers.⁵

הפרקטיקה של מיפוי קובץ כזיכרון משותף (שיתוף בעל שם, סנכרון, דפוסי תקלה) מטופלת ב«המלכודות של הזיכרון המשותף ושיטות העבודה המומלצות בפועל».

7. Fast I/O — סגירת שיעורי הבית מפרק 1

קודם בשתי שורות. Fast I/O הוא דרך קצרה שהוכנה לקריאה וכתיבה סינכרוניות לקובץ שכבר במטמון; הוא מחליף נתונים ישירות עם המטמון בלי לבנות IRP (חבילת בקשת קלט/פלט — המיכל שבו הליבה מוסרת בקשה למנהל). בעמודת Operation של Procmon מתערבבים IRP_MJ_READ ו-FASTIO_READ כי אותה «קריאה» עברה בנתיב הרגיל או בדרך הקצרה.

בסעיף 5.2 בפרק 1 כתבנו ש«לא כל קלט/פלט הופך ל-IRP». הנה התשובה.

לקובץ שיושב במטמון ידוע שקריאה וכתיבה מסתיימות בהעתקת זיכרון מול המטמון, בלי לטרוח לבנות IRP ולהזרים במחסנית ההתקנים. לכן Windows מכינה לקלט/פלט סינכרוני לקובץ שבמטמון דרך קצרה בשם Fast I/O: אינו בונה IRP, קורא ישירות ל«נקודות הכניסה של Fast I/O» של מערכת הקבצים, ומעתיק ישירות ממנהל המטמון.⁶ כש-Fast I/O אינו יכול לטפל (אין במטמון, מעורבת נעילה, מסנן מתערב וכו’) חוזרים לנתיב IRP הרגיל. שימו לב שזו דרך מהירה לבקשה סינכרונית דווקא, ולא «פגיעה במטמון = תמיד Fast I/O». פעולות על handle אסינכרוני (FILE_FLAG_OVERLAPPED) עשויות לעבור בנתיב IRP גם כשהן מסתיימות במקום מהמטמון (פרק 2, סעיף 5).

flowchart TB
    REQ["קריאה וכתיבה סינכרוניות ל-handle עם מטמון מופעל"]
    Q{"האם Fast I/O יכול לטפל<br/>（כבר במטמון וכו'）"}
    FAST["Fast I/O<br/>העתקה ישירה עם המטמון בלי IRP<br/>ב-Procmon מוצג כ-FASTIO_"]
    IRP["הנתיב הרגיל<br/>בונים IRP ושולחים למחסנית ההתקנים<br/>（עולם איור 6 מפרק 1）"]
    REQ --> Q
    Q -->|יכול| FAST
    Q -->|לא יכול| IRP

איור 8: פיצול Fast I/O. לכן ב-Procmon נראים מעורבבים FASTIO_READ ו-IRP_MJ_READ

למה בתצפית Procmon בפרק 1, סעיף 7 התערבבו שורות FASTIO_ — זה מסביר. לקריאה שפגעה במטמון, אפילו IRP הוא מותרות. קיום הנתיב הזה משפיע גם על מנהלי המסנן בפרק 6 (מיניפילטר יכול להתערב גם ב-Fast I/O).

8. סיכום

• מטמון הקבצים של Windows הוא write-back, והזהות האמיתית היא מיפוי מקטעי 256KB של קובץ. קריאה וכתיבה עם מטמון מופעל הופכות להעתקת זיכרון מול משבצת.¹
• את הקריאה קריאה מראש משערת, ו-SequentialScan/RandomAccess הם הרמזים לכך.¹
• הכתיבה מודבקת בידי lazy writer כל שנייה. גם אם היישום מת הנתונים נשארים, ואם מערכת ההפעלה כולה מתה נעלם רק החלק המלוכלך. שאלת התכנון היא «האם מותר לנתונים האלה להיאבד ברגע של הפסקת חשמל?»¹
• הכלים לכתוב בוודאות הם FlushFileBuffers (אישור באבן דרך) / WRITE_THROUGH (בכל כתיבה) / NO_BUFFERING (בלי מטמון + דרישות יישור). שטיפה בכל פעם אינה יעילה; לעמידות תכופה ההמלצה הרשמית היא שילוב NO_BUFFERING+WRITE_THROUGH. שימו לב גם שמטא-נתונים תמיד במטמון.²³¹
• תצוגה ממופה והמטמון חולקים את אותם דפים והם עקביים. מחוץ למעגל רק NO_BUFFERING. הפיכת מיפוי לעמיד היא שני שלבים: FlushViewOfFile+FlushFileBuffers.⁴⁵
• קריאה וכתיבה סינכרוניות שפגעו במטמון מדלגות אפילו על IRP דרך Fast I/O. זו הזהות האמיתית של רשומות FASTIO_ שראינו ב-Procmon בפרק 1.⁶

ההמשך הוא פרק 5, «המבנה הפנימי של NTFS — מערכת קבצים מתוך הבנת MFT». עד כאן טיפלנו בקובץ כ«היסט ורצף בתים»; מכאן יורדים אל איך NTFS באמת מסדרת נתונים בדיסק — MFT, כמה זרמי נתונים, היומן, קישורים קשיחים — אל המבנה הסטטי שעל הדיסק עצמו.

מאמרים קשורים

• מעמקי הקלט/פלט ב-Windows (פרק 1) — כל קריאה וכתיבה הופכות ל-IRP: התמונה הכללית של מערכת הקלט/פלט
• מעמקי הקלט/פלט ב-Windows (פרק 2) — קלט/פלט סינכרוני ואסינכרוני: המשמעות האמיתית של OVERLAPPED
• מעמקי הקלט/פלט ב-Windows (פרק 3) — יציאות השלמת קלט/פלט (IOCP) ומאגר התהליכונים של .NET: המרתף של async/await
• ידע בסיסי על בקרת הרשאות בלעדיות בהעברת קבצים - נעילת קבצים ושיטות עבודה מומלצות ל-claim אטומי
• המלכודות של הזיכרון המשותף ושיטות העבודה המומלצות בפועל
• שימוש ב-SQLite ביישום עסקי מ-C# — מצב WAL, נעילה בלעדית, הגנה מפני פגיעה, והבחירה מול EF Core
• איך משווים נכון מהירות בין גרסאות תוכנה ב-Windows
• איך לטפל בהתקני USB מיישום Windows — בחירה בין COM וירטואלי, HID, WinUSB ו-SDK ייעודי

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בתכנון ובחקירת קלט/פלט קבצים ביישומים עסקיים ל-Windows — מקרים כמו «נתונים שחשבתי ששמרתי נעלמו» או «כתיבה לקובץ איטית, או מהירה באופן חשוד».

• פיתוח יישומי Windows
• חקירת תקלות ואיתור גורמים
• שימוש חוזר בנכסים קיימים והעברתם
• יצירת קשר

מקורות

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

ברגע ש-WriteFile החזיר הצלחה, האם הנתונים כבר נכתבו לדיסק?

כברירת מחדל לא. מטמון הקבצים של Windows הוא מטמון write-back, ו-WriteFile מחזיר הצלחה ברגע שהעתיק את הנתונים למטמון הקבצים של המערכת. הכתיבה לדיסק נעשית אחר כך בידי lazy writer של מנהל המטמון, שמופעל פעם בשנייה. מה שחשוב הוא ההבדל לפי סוג הכשל. גם אם תהליך היישום קורס, נתונים שנכנסו למטמון אינם אובדים — כל עוד מערכת ההפעלה חיה, היא תכתוב אותם אחר כך. לעומת זאת, בכשל שבו נופלת מערכת ההפעלה כולה (הפסקת חשמל, מסך כחול), מטמון מלוכלך שעדיין לא נכתב אובד. הקריאה המדויקת של «WriteFile הצליח» אינה «נעשה עמיד» אלא «נמסר למערכת ההפעלה».

איך מבטיחים שהנתונים באמת מגיעים לדיסק?

יש שלושה כלים. הראשון הוא FlushFileBuffers, שכותב עד הסוף אל ההתקן את כל הנתונים והמטא-נתונים שנאגרו לקובץ הזה (ב-.NET המקבילה היא FileStream.Flush(true)). השני הוא FILE_FLAG_WRITE_THROUGH, שכותב בכל כתיבה גם למטמון וגם מיד לדיסק. השלישי הוא FILE_FLAG_NO_BUFFERING, שאינו עובר במטמון כלל. התיעוד של Microsoft מציין שקריאה ל-FlushFileBuffers בכל כתיבה אינה יעילה, ושליישומים שזקוקים לעמידות אמינה בכתיבות תכופות כדאי לשלב FILE_FLAG_NO_BUFFERING עם FILE_FLAG_WRITE_THROUGH. כולם מוותרים על חלק מתועלת המטמון ולכן נעשים איטיים יותר, ולכן בפועל לא «שמים על הכול» אלא מצמצמים לכתיבות של נתונים שאי אפשר להרשות לעצמנו לאבד.

מה ההבדל בין FILE_FLAG_WRITE_THROUGH ל-FILE_FLAG_NO_BUFFERING?

WRITE_THROUGH פירושו «עדיין כותבים למטמון, אבל לפני ההשלמה כותבים גם לדיסק». קריאות ממשיכות ליהנות מהמטמון; מוסר רק עיכוב ה-lazy writer בכתיבות. NO_BUFFERING פירושו «קריאה וכתיבה אינן עוברות במטמון המערכת», כך ששתיהן הופכות לקלט/פלט אל ההתקן בכל קריאה (אבל מה שעוקפים הוא רק את מטמון Windows עצמו — לא מדלגים על מטמון כתיבה שיושב בתוך התקן האחסון). בתמורה מגיעות מגבלות קשיחות: גודל והיסט הקובץ של כל קריאה או כתיבה חייבים להיות כפולה שלמה של גודל המגזר של הכרך, וגם כתובת המאגר חייבת להיות מיושרת לגבול מגזר פיזי. וגם עם NO_BUFFERING, מטא-נתונים של מערכת הקבצים ממשיכים להיות במטמון, ולכן כדי להפוך גם מטא-נתונים לעמידים עדיין צריך FlushFileBuffers או WRITE_THROUGH מעליו. בדרך כלל משתמשת בזה תוכנה שמנהלת מאגרים בעצמה, כמו מנוע מסד נתונים; ביישום רגיל סביר להתחיל מ-WRITE_THROUGH או FlushFileBuffers.

במנהל המשימות נראה מעט זיכרון פנוי — האם זו אשמת מטמון הקבצים?

לעיתים קרובות כן, וזו התנהגות תקינה. Windows משתמשת בזיכרון פיזי פנוי באופן פעיל כמטמון קבצים, ולכן העתקת קובץ גדול או הרבה קריאה וכתיבה מנפחות את המטמון והשימוש בזיכרון נראה גבוה יותר. עם זאת, רוב הדפים שהמטמון משתמש בהם הם מסוג שאפשר למחזר די במהירות ברגע שיישום מבקש זיכרון, וצריך להבדיל זאת ממצב של «הזיכרון נאכל ולא מספיק». כשחושדים במחסור אמיתי, מעשי יותר להסתכל לא רק על כמות הפנוי הנראית אלא גם על זיכרון committed ועל תדירות hard fault.

אם נוגעים באותו קובץ גם דרך תצוגה ממופה לזיכרון וגם דרך ReadFile/WriteFile, התוכן יכול להיסחף?

מול קלט/פלט רגיל עם מטמון מופעל — לא. המטמון של Windows עצמו ממומש כמיפוי קובץ, ולכן תצוגה ממופה והמטמון של אותו קובץ מקומי חולקים את אותם נתונים — שינוי דרך האחד נראה גם דרך השני. גם כמה תהליכים שיוצרים תצוגות מאותו אובייקט מיפוי קובץ רואים נתונים קוהרנטיים (עקביים). אבל קריאה וכתיבה ב-handle שנפתח עם FILE_FLAG_NO_BUFFERING עוקפות את המטמון ויוצאות ממסגרת העקביות הזו. וגם, כדי לכתוב בוודאות לדיסק שינויים שנעשו דרך תצוגה ממופה, FlushViewOfFile לבדו אינו מספיק — הוא אינו כותב מטא-נתונים ואינו ממתין למטמון החומרה — ולכן אחרי FlushViewOfFile צריך לקרוא ל-FlushFileBuffers.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.