Windows I/Oの深層(第4回) ── キャッシュマネージャー:あなたのWriteFileはいつディスクに届くのか

WriteFile が成功を返しました。さて、データはいまどこにあるでしょうか。

答えは、ほぼ確実にまだディスクにありません。メモリ上のキャッシュにコピーされただけです。だから「保存したのに、電源断で戻ったら消えていた」が起こり、だからファイルコピーのベンチマークが物理的にありえない速度を叩き出し、だからデータベースは律儀にfsyncを呼びます。

連載「Windows I/Oの深層」の第4回は、この間に立つキャッシュマネージャーです。第2回で「キャッシュに載っていれば非同期I/Oも同期完了する」と書き、第1回では「IRPを作らない近道(ファストI/O)」を宿題にしました。今回その伏線をすべて回収します。

1. まず結論

• Windowsのファイルキャッシュはライトバック方式です。読みはまずシステムファイルキャッシュから、書きもまずキャッシュへ。ディスクへの反映はOSが後から行います。¹
• キャッシュの実体はファイルマッピングです。キャッシュマネージャーはファイルの256KB単位の区間をシステムのアドレス空間にマップし、読み書きは「そのビューとの間のメモリコピー」になります(2章)。¹
• 書き込みは毎秒の遅延書き込み(lazy writer)が後追いで反映します。アプリのクラッシュではデータは失われませんが、電源断やOSクラッシュではダーティなキャッシュが失われます(4章)。¹
• 「確実に書く」道具は3つ。FlushFileBuffers(=.NETの Flush(true))、FILE_FLAG_WRITE_THROUGH、FILE_FLAG_NO_BUFFERING。頻繁な書き込みでの毎回フラッシュは非効率で、公式ドキュメントはNO_BUFFERING+WRITE_THROUGHの併用を挙げています(5章)。²¹
• NO_BUFFERINGには整列要件があります。サイズ・オフセットはセクターサイズの整数倍、バッファアドレスも物理セクター境界に整列。そしてNO_BUFFERINGでもメタデータはキャッシュされ続けます(5.3節)。³¹
• マップビューとキャッシュは同じデータを共有します。メモリマップトファイルと通常のキャッシュI/Oは一貫しており、マップの永続化は FlushViewOfFile+FlushFileBuffers の2段です(6章)。⁴⁵
• キャッシュに乗った同期の読み書きは、IRPすら作らないことがあります。ファストI/Oという近道がキャッシュマネージャーへ直行します──第1回の宿題の答えです(7章)。⁶

この記事の知識マップ

WriteFileの成功はディスクへの永続化を意味せず、Windowsのファイルキャッシュはまずシステムキャッシュビューへコピーし、ディスクへの反映はlazy writerが毎秒後追いします。電源断やOSクラッシュではまだ書かれていないダーティページが失われるため、確実に書きたいデータには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による確実な書き込み、整列要件、メモリマップトファイルとの一貫性、ファストI/Oの関係を示す図
    cache_manager["キャッシュマネージャー"]
    write_behind_caching["ライトバックキャッシュ(遅延書き込み方式)"]
    memory_mapped_file["ファイルマッピング(メモリマップトファイル)"]
    system_cache_view["システムキャッシュビュー(256KBスロット)"]
    file_object["ファイルオブジェクト"]
    lazy_writer["lazy writer(遅延書き込みスレッド)"]
    unflushed_write_loss["未反映データの喪失"]
    temp_file_attribute["FILE_ATTRIBUTE_TEMPORARY"]
    dirty_page["ダーティページ"]
    power_loss["電源断・OSクラッシュ"]
    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["ファストI/O"]
    procmon["Process Monitor(procmon.exe)"]
    irp["IRP(I/O要求パケット)"]
    synchronous_io["同期I/O"]
    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: キャッシュ有効I/Oの実像。アプリから見た「ファイルの読み書き」は、多くの場合ただのメモリコピー

誤解しやすい点をひとつ。256KBはビュー(マップ)の粒度であって、ディスクI/Oが常に256KB単位で行われるという意味ではありません。スロット内のページは必要に応じて読み込まれ、実際にディスクへ飛ぶI/Oの量は要求サイズやアクセスパターンで変わります。初めて読む区間なら、充填のためにディスクI/Oが発生します(ここで第1回のIRPが下位のストレージスタックへ飛びます)。すでにキャッシュにあれば、読み取りはコピーだけで完了します。第2回5章で見た「キャッシュヒットだと非同期発行しても同期完了する」のは、この「即答できる要求はその場で完了させる」動きの現れでした。逆に、キャッシュ有効のままページがメモリに無い場合、ページフォールト処理に非同期の仕組みがないため非同期読み取りが同期的に処理されることがある──という罠も第2回で見たとおりです。⁷

2.2. 「空きメモリが減った」の正体

キャッシュを使うかどうかや先読みの状態は開き方ごと(ファイルオブジェクト単位)に管理されますが¹、キャッシュされたデータ本体はファイル(ストリーム)単位で共有されます。同じファイルを何度開いても、別々のキャッシュができるわけではなく、どのハンドルからも同じキャッシュ内容が見えます(6章の一貫性の土台です)。キャッシュはWindowsが動いている間ずっとキャッシュマネージャーの指揮下で動きます。¹ 大きなファイルをコピーしたり大量に読み書きすれば、空いている物理メモリはどんどんキャッシュに転用されます。タスクマネージャーの空きメモリが減って見えても、その多くは「アプリが要求すればすみやかに明け渡される、価値ある使われ方をしている待機中のメモリ」です。メモリ不足の診断でこの区別を誤らないために、観測の実務は「.NETでGC待ちとメモリリークを見分ける」でも扱いました。

この動きは画面で確かめられます。タスクマネージャー > パフォーマンス > メモリ を開くと、下側の「メモリの構成」バーが 使用中 / 変更済み / スタンバイ / 空き に区切られています。ファイルキャッシュの大半はこのスタンバイに入り、右側の一覧では「キャッシュ済み」として合計されています。もっと細かく見るなら リソースモニター > メモリ タブ で、同じ区分が容量つきで並びます。数GBのファイルを1本コピーしてから見直すと、スタンバイが増えて空きが減るのに、「使用中」はほとんど変わらない──つまり「メモリが食い潰された」のではなく「空いていたメモリがキャッシュに使われた」ことが目で確認できます。

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のフラグでヒントを与えられる

第1回の対応表に載せた FileOptions.SequentialScan / RandomAccess は、この先読みエンジンへのヒントです。「全部なめる」バッチ処理には前者、インデックスを辿るようなアクセスには後者──アプリしか知らない未来を、OSに教えるためのフラグだと考えると使いどころが明確になります。

4. 遅延書き込み ── WriteFileの「成功」の意味

4.1. lazy writerは毎秒やってくる

書き込み側はライトバックキャッシュです。WriteFile はデータをスロットへコピーした時点で成功を返し、ディスクへの反映は後回しにされます。この「遅らせて書く」方針が遅延書き込み(lazy writing)です。¹

反映を担うのが、キャッシュマネージャーが毎秒起動するlazy writerです。最近フラッシュされていないページの8分の1をキューに積んで書き出し、書くべきデータが多ければさらに積み増します。なお、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/>電源断・OSクラッシュならこのデータは消える
    LW->>C: ダーティページの1/8を選ぶ
    LW->>D: まとめて書き戻す
    Note over D: ここで初めて永続化される

図3: 遅延書き込み。WriteFileの成功は「OSに引き渡した」であって「永続化された」ではない

4.2. 何が起きたら、どこまで消えるのか

「危険な窓」の意味を正確にしておきます。障害の種類で運命が分かれます。

flowchart TB
    W["WriteFile成功直後のデータ<br/>(キャッシュ上のダーティページ)"]
    Q{"何が起きたか"}
    A1["アプリのプロセスが<br/>クラッシュ/強制終了"]
    A2["OSごと停止<br/>(電源断・ブルースクリーン)"]
    S["データは残る<br/>キャッシュはOSのものなので<br/>lazy writerが予定どおり書き戻す"]
    L["ダーティページは失われる<br/>ディスクに届いていた分だけが残る"]
    W --> Q
    Q --> A1
    Q --> A2
    A1 --> S
    A2 --> L

図4: 障害の種類と生存の分かれ目。キャッシュは「プロセスの持ち物」ではなく「OSの持ち物」

• アプリが死んでもデータは消えません。キャッシュへのコピーが済んだ時点で、データの所有者はOSです。「保存直後にアプリが落ちたのにファイルは無事だった」のはこのおかげです。
• OSごと死ぬとダーティ分は消えます。フラッシュの頻度は性能と信頼性のトレードオフとして調整されており、「突然の電源喪失が起これば、キャッシュされたデータは失われる」とドキュメントも明記しています。¹

つまり業務アプリの設計での問いは、「このデータは、電源断の瞬間に失われてよいか」です。ログの数秒分なら許せるかもしれません。受注データの確定レコードなら許せないでしょう。許せないものにだけ、次章の道具を使います。

5. 「確実に書いた」を作る道具箱

5.1. FlushFileBuffers ── 今すぐ書き切れ

FlushFileBuffers は、指定したファイルのバッファ済みデータをデバイスへ書き切ります。ファイルシステムのメタデータは常にキャッシュされるため、メタデータまで確実に届けるにはフラッシュ(またはWRITE_THROUGH)が必要、という点も押さえどころです。¹² .NETでは FileStream.Flush(true) がこれに相当します(Flush() だけでは.NET内部のバッファをOSへ渡すだけで、OSのキャッシュはそのままです)。⁸

ただし公式ドキュメントは明確に釘を刺しています──書き込みのたびに毎回呼ぶのは非効率です。多数の書き込みで毎回の永続化が必要なら、後述の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 は読み書きからシステムキャッシュそのものを外します。すべての読み書きが、キャッシュを経由せず毎回ディスク装置へのI/Oになります。¹ ただし迂回できるのはWindowsのシステムキャッシュまでで、図5のとおり装置内の書き込みキャッシュは別の段です。電源断耐性まで求めるなら、WRITE_THROUGH の併用や FlushFileBuffers が引き続き必要です。大量データの一括転送や、自前でバッファ管理をするデータベースエンジンのための道具ですが、厳しい約束事が付きます。³

• 読み書きのサイズとファイルオフセットは、ボリュームのセクターサイズの整数倍であること(512バイトセクターなら512・1024・1536…)。
• バッファのアドレスも物理セクターサイズに整列していること(4096バイト物理セクターの「Advanced Format」ディスクへの配慮も必要)。
• それでもメタデータはキャッシュされ続けるので、完全な永続化にはWRITE_THROUGHの併用か FlushFileBuffers が要ります。¹²

この「約束事」は、フラグを足すだけで済ませようとした人が最初に転ぶところです。整列を守らないまま読み書きすると、ERROR_INVALID_PARAMETER(87) で失敗します。守るべき3点を整理します。³

3つ目が特に見落とされます。malloc や new、C#の配列が返すアドレスには、セクター境界への整列の保証がありません。ページ境界に確保できる VirtualAlloc を使えば、物理セクター4096バイトの「Advanced Format」ディスクの要件も同時に満たせます。最小の形はこうなります。

// 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)
{
    // buffer の先頭 read バイトを処理する
    // (ファイル末尾では read < chunk になる。これは正常)
}

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

なお、.NETの FileOptions には 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: データの階層と、各道具がどこまで押し込むか。「ディスク装置内のキャッシュ」という最後の一段にも注意

選ぶ順番は、「電源断で何件まで失ってよいか」を先に決め、次に「そのためにどれだけ遅くなってよいか」を確認する、の2段です。表を上から眺めるのではなく、この分岐をたどってください。

flowchart TB
    S["このデータを書こうとしている"]
    Q1{"電源断・ブルースクリーンの瞬間に<br/>失われても許されるか"}
    A0["既定のまま(キャッシュ有効)<br/>いちばん速い。ほとんどのI/Oはここ"]
    Q2{"失えないのは<br/>「節目」か「1件ごと」か"}
    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 -->|"1件ごと"| Q3
    Q3 -->|"いいえ(通常のアプリ)"| A2
    Q3 -->|"はい(DBエンジン等)"| A3

図6: 道具の選び方。1段目の分岐が信頼性の要求、2段目が払えるコスト。「1件ごとに FlushFileBuffers」という道が無いのは、5.1で見たとおり公式ドキュメントがそれを非効率としているためです

実務のパターンも3つだけ挙げておきます。

1. 「一時ファイルに書く→フラッシュ→リネーム」が、壊れかけファイルを残さない定石です。中身を書き切ってから名前で確定する──この原子的な受け渡しは「ファイル連携の排他制御の基礎知識」で詳しく扱いました。
2. データベースに任せるのも立派な設計です。SQLiteがWALとフラッシュで耐久性を作り込んでいる話は「C#でSQLiteを業務アプリに使う」を参照してください。「自分でフラッシュ戦略を書かない」という選択肢は常にあります。
3. ベンチマークはキャッシュを疑う。「読みが速すぎる」測定はたいてい2回目以降のキャッシュヒットを測っています。測定の作法は「Windowsでプログラムのバージョン別速度を正しく比較する方法」にまとめています。

なお図5の最後の一段──ディスク装置内のキャッシュも忘れないでください。FlushFileBuffers はそこまで含めた書き切りを求めますが、USBメモリや外付けディスクでは装置側の書き込みキャッシュポリシー(「クイック取り外し」と「高パフォーマンス」)が絡みます。取り外し可能デバイスの扱いは「WindowsアプリでUSB機器を扱う方法」も参照してください。

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のI/Oは<br/>この共有の枠外(直接ディスクへ)"]
    NB -.-> DISK

図7: マップビューもキャッシュも、同じ「ファイルに裏打ちされたページ」を見ている。枠外にいるのはNO_BUFFERINGだけ

注意点は2つです。

• FILE_FLAG_NO_BUFFERING のI/Oはこの一貫性の枠外です。キャッシュを経由しない読み書きと、マップビュー/キャッシュ経由の内容は突き合わされません。混ぜるなら自分で整合を取る必要があります。
• マップビューの永続化は2段構えです。FlushViewOfFile は範囲内のダーティページの書き出しを開始しますが、メタデータは書かず、ディスク装置のキャッシュからの物理書き込みも待ちません。確実に届けるには FlushViewOfFile の後に FlushFileBuffers を呼びます。⁵

共有メモリとしてのファイルマッピングの実務(名前付き共有、同期、事故パターン)は「共有メモリの落とし穴と実務ベストプラクティス」で扱っています。

7. ファストI/O ── 第1回の宿題回収

先に2行で。ファストI/Oとは、キャッシュに載っているファイルへの同期の読み書きのために用意された近道で、IRP(I/O要求パケット。カーネルがドライバーに渡す要求の入れ物)を組み立てずにキャッシュと直接データをやり取りします。ProcmonのOperation列に IRP_MJ_READ と FASTIO_READ が混ざって出るのは、同じ「読み取り」が通常経路と近道のどちらを通ったかの違いです。

第1回5.2節で「すべてのI/OがIRPになるわけではない」と書きました。答え合わせです。

キャッシュに乗っているファイルの読み書きは、IRPを組み立ててデバイススタックを流すまでもなく、キャッシュとのメモリコピーで済むことが分かっています。そこでWindowsは、キャッシュされたファイルへの同期I/OのためにファストI/Oという近道を用意しています──IRPを作らず、ファイルシステムの「ファストI/Oエントリポイント」を直接呼び、キャッシュマネージャーから直接コピーする経路です。⁶ ファストI/Oで処理できない場合(キャッシュに無い、ロックが絡む、フィルターが割り込む等)は、通常のIRP経路へ折り返します。なお、これは同期の要求のための高速経路であって「キャッシュヒット=常にファストI/O」ではありません。非同期(FILE_FLAG_OVERLAPPED)ハンドルの操作は、キャッシュからその場で完了する場合(第2回5章)でもIRP経路で処理されることがあります。

flowchart TB
    REQ["キャッシュ有効ハンドルへの同期的な読み書き"]
    Q{"ファストI/Oで処理できるか<br/>(キャッシュに載っている等)"}
    FAST["ファストI/O<br/>IRPを作らずキャッシュと直接コピー<br/>ProcmonではFASTIO_と表示"]
    IRP["通常経路<br/>IRPを組み立ててデバイススタックへ<br/>(第1回の図6の世界)"]
    REQ --> Q
    Q -->|できる| FAST
    Q -->|できない| IRP

図8: ファストI/Oの分岐。Procmonで FASTIO_READ と IRP_MJ_READ が混ざって見えるのはこのため

第1回7章のProcmon観察で FASTIO_ の行が混ざっていた理由が、これで説明できます。キャッシュヒットの読み取りは、IRPすら贅沢品なのです。この経路の存在は、第6回で扱うフィルタードライバーにも影響します(ミニフィルターはファストI/Oにも割り込めるようになっています)。

8. まとめ

• Windowsのファイルキャッシュはライトバックで、実体はファイルの256KB区間のマッピングです。キャッシュ有効の読み書きはスロットとのメモリコピーになります。¹
• 読みは先読みが投機し、SequentialScan/RandomAccess はそのヒントです。¹
• 書きは毎秒のlazy writerが後追いします。アプリが死んでもデータは残り、OSごと死ぬとダーティ分だけが消えます。設計の問いは「このデータは電源断の瞬間に失われてよいか」です。¹
• 確実に書く道具は FlushFileBuffers(節目の確定)/WRITE_THROUGH(書き込みごと)/NO_BUFFERING(キャッシュ非経由+整列要件)。毎回フラッシュは非効率で、頻繁な永続化にはNO_BUFFERING+WRITE_THROUGH併用が公式の推奨です。メタデータが常にキャッシュされる点にも注意。²³¹
• マップビューとキャッシュは同じページを共有し一貫します。枠外はNO_BUFFERINGのみ。マップの永続化は FlushViewOfFile+FlushFileBuffers の2段です。⁴⁵
• キャッシュヒットの同期の読み書きはファストI/OでIRPすら省略されます。第1回のProcmonで見た FASTIO_ の正体です。⁶

続きは第5回「NTFSの内部構造 ── MFTから理解するファイルシステム」です。今回まではファイルを「オフセットとバイト列」として扱ってきましたが、その裏でNTFSがどうデータを配置しているのか──MFT、複数データストリーム、ジャーナル、ハードリンク──ディスクの上の静的な構造へ降りていきます。

関連記事

• Windows I/Oの深層(第1回) ── すべての読み書きはIRPになる:I/Oシステムの全体像
• Windows I/Oの深層(第2回) ── 同期I/Oと非同期I/O:OVERLAPPEDの本当の意味
• Windows I/Oの深層(第3回) ── I/O完了ポート(IOCP)と.NETスレッドプール:async/awaitの地下室
• ファイル連携の排他制御の基礎知識 - ファイルロックと原子的 claim のベストプラクティス
• 共有メモリの落とし穴と実務ベストプラクティス
• C#でSQLiteを業務アプリに使う ── WALモード・排他制御・破損対策・EF Coreとの使い分け
• Windowsでプログラムのバージョン別速度を正しく比較する方法
• WindowsアプリでUSB機器を扱う方法 ── 仮想COM・HID・WinUSB・専用SDKの選び方

関連する相談領域

合同会社小村ソフトでは、「保存したはずのデータが消えた」「ファイル書き込みが遅い/速すぎて怪しい」といったWindows業務アプリのファイルI/Oの設計・不具合調査を扱っています。

• Windowsアプリ開発
• 不具合調査・原因解析
• 既存資産活用・移行支援
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

WriteFileが成功を返した時点で、データはディスクに書かれていますか？

既定では書かれていません。Windowsのファイルキャッシュはライトバック方式で、WriteFileはデータをシステムファイルキャッシュにコピーした時点で成功を返します。ディスクへの書き込みは、キャッシュマネージャーが毎秒起動する遅延書き込み(lazy writer)が後から行います。重要なのは障害の種類による差です。アプリのプロセスがクラッシュしても、キャッシュに入ったデータはOSが生きている限り後で書かれるので失われません。一方、OSごと落ちる障害(電源断、ブルースクリーン)では、まだ書かれていないダーティなキャッシュは失われます。「WriteFileが成功した=永続化された」ではなく、「成功した=OSに引き渡した」と理解するのが正確です。

確実にディスクへ書き込むにはどうすればよいですか？

3つの道具があります。第一にFlushFileBuffersで、そのファイルのバッファ済みデータとメタデータをデバイスへ書き切ります(.NETならFileStream.Flush(true)がこれに相当します)。第二にFILE_FLAG_WRITE_THROUGHで、書き込みのたびにキャッシュへ書きつつ即座にディスクへも書きます。第三にFILE_FLAG_NO_BUFFERINGで、キャッシュ自体を経由しません。マイクロソフトのドキュメントは、書き込みのたびにFlushFileBuffersを呼ぶのは非効率で、頻繁な書き込みで確実な永続化が必要ならFILE_FLAG_NO_BUFFERINGとFILE_FLAG_WRITE_THROUGHの併用を使うべきとしています。どれもキャッシュの恩恵を手放すぶん遅くなるので、「全部に付ける」のではなく、失えないデータの書き込みに絞って使うのが実務の勘所です。

FILE_FLAG_WRITE_THROUGHとFILE_FLAG_NO_BUFFERINGはどう違いますか？

WRITE_THROUGHは「キャッシュには書くが、完了前にディスクにも書く」です。読み取りは引き続きキャッシュの恩恵を受けられ、遅延書き込みの遅延だけを取り除きます。NO_BUFFERINGは「読み書きがシステムキャッシュを経由しない」で、読みも書きも毎回ディスク装置へのI/Oになります(ただし迂回するのはWindowsのキャッシュまでで、装置内の書き込みキャッシュまで飛ばすわけではありません)。その代わり厳しい制約が付きます。読み書きのサイズとファイルオフセットはボリュームのセクターサイズの整数倍でなければならず、バッファのアドレスも物理セクター境界に整列させる必要があります。また、NO_BUFFERINGでもファイルシステムのメタデータはキャッシュされ続けるため、メタデータまで確実に書くにはFlushFileBuffersかWRITE_THROUGHの併用が必要です。データベースエンジンのように自前でバッファ管理をするソフトウェアが使うのが典型で、通常のアプリではまずWRITE_THROUGHやFlushFileBuffersから検討するのが順当です。

タスクマネージャーで空きメモリが少なく見えるのは、ファイルキャッシュのせいですか？

多くの場合そうで、しかも正常な動作です。Windowsは空いている物理メモリを積極的にファイルキャッシュとして使い、大きなファイルコピーや大量の読み書きをすれば、その分キャッシュが膨らんでメモリ使用量が増えて見えます。ただしキャッシュが使っているページの多くは、アプリがメモリを要求すれば比較的すみやかに転用される種類のもので、「メモリが食い潰されて足りない」状態とは区別が必要です。メモリ不足を疑う際は、見かけの空き容量だけでなく、コミット済みメモリやハードフォールトの頻度といった指標を見るのが実務的です。

メモリマップトファイルとReadFile/WriteFileで同じファイルを触ると、内容はずれませんか？

通常のキャッシュ有効I/Oとの間ではずれません。Windowsのキャッシュ自体がファイルマッピングで実装されており、同じローカルファイルに対するマップビューとキャッシュは同じデータを共有するため、一方の変更はもう一方からも見えます。複数プロセスが同じファイルマッピングオブジェクトからビューを作った場合もデータはコヒーレント(一貫)です。ただし、FILE_FLAG_NO_BUFFERINGで開いたハンドルの読み書きはキャッシュを経由しないため、この一貫性の枠外になります。またマップビューの変更を確実にディスクへ書くには、FlushViewOfFileだけではメタデータが書かれずハードウェアのキャッシュも待たないため、FlushViewOfFileの後にFlushFileBuffersを呼ぶ必要があります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。