仮想ファイルシステムを導入して開発環境のストレージ課題を解消する

by SEGADevTech

Slide 1

Slide 1 text

仮想ファイルシステムを導入して開発環境のストレージ課題を解消する！

Slide 2

Slide 2 text

2 ©SEGA 自己紹介株式会社セガ技術本部開発技術部山田英伸 SEGA入社後、業務用ゲームタイトルの下回りライブラリ開発やツール作成などに従事。現在は、特定の専門分野を持たず、幅広い領域で色々とやっています講演歴 - Unite Tokyo 2019 「大量のアセットも怖くない～HTTP/2による高速な通信の実装例」 - CEDEC 2021 「ダウンロード時間を大幅減！～大量のアセットをさばく高速な実装と運用事例の共有～」

Slide 3

Slide 3 text

3 ©SEGA 自己紹介株式会社セガ第3事業部第3オンライン研究開発プログラム1部高橋陸『ファンタシースターオンライン2』ではアクションパートを担当。『PSO2 ニュージェネシス』ではCI/CD管理、デプロイ業務に従事

Slide 4

Slide 4 text

4 ©SEGA 自己紹介株式会社セガフェイブ AMインフラ研究開発部阿部輝仁アーケードコンテンツ開発部門のプログラマーとしてキャリアをスタート。海外スタジオへの出向・ハードウェア開発部門への異動などを経て、活動領域にこだわらず様々なソフトウェア開発を経験。

Slide 5

Slide 5 text

5 ©SEGA • 本講演内容の撮影、SNS投稿は OK • 後日、CEDiLで資料を公開 • 講演中の質疑が可能です。コメント欄に書き込んでください

Slide 6

Slide 6 text

6 ©SEGA • ３分でわかる講演の要点 • 仮想ファイルシステムとは • ProjFS と SlimSync • 『PSO2 ニュージェネシス』開発環境での効果 • ProjFS の組み込み TIPS • まとめアジェンダ

Slide 7

Slide 7 text

7 ©SEGA ３分でわかる講演の要点

Slide 8

Slide 8 text

8 ©SEGA • ゲーム開発の規模が大きく – アセットの種類・サイズが増加 – バージョン違いによる並行開発開発環境の現状と課題開発に必要なデータを置いておくため、開発ストレージは常にギリギリで、負荷が大きい状況

Slide 9

Slide 9 text

9 ©SEGA • 「SlimSync」: リポジトリ同期ツール – Windows用仮想ファイルシステムを活用 – バージョン管理下の全ファイルが「ある」ように見えるツールを開発リポジトリからのデータ取得を仮想ファイルシステムによってオンデマンド化＆シームレス化し、開発者のリポジトリ同期に要する時間やストレージ容量を節約するツール

Slide 10

Slide 10 text

10 ©SEGA • 『PSO2 ニュージェネシス』(以下『NGS』）で仮想ファイルシステムを使った効果 – ストレージを消費している実容量 – リポジトリの取得(同期)に要した時間検証結果

Slide 11

Slide 11 text

11 ©SEGA • ストレージの実使用量は、従来の1%以下に！ • リポジトリ同期の時間が、従来の17%に！検証結果 (の一部) 約1.2GB 約1TBは仮想状態のまま約176分 83% 削減！約30分

Slide 12

Slide 12 text

12 ©SEGA • 効果 – 実際のプロジェクトでの検証結果を共有 • これから実装する人向け – 仮想ファイルシステム • 動作の概要と仕組み – 実装や取扱いの注意点講演のポイント

Slide 13

Slide 13 text

仮想ファイルシステムとは

Slide 14

Slide 14 text

14 ©SEGA • 「仮想ファイルシステム」でイメージするもの – 仮想マシンの “仮想ハードディスク” – Unix系OSのVFS (Virtual File System) – 仮想ファイルを扱うもの • ネットワーク越しに扱うもの – NFS, CIFS, クラウドストレージなど仮想ファイルシステムとは

Slide 15

Slide 15 text

15 ©SEGA • Unix系 VFS の場合 – 普段は一番上の状態を見ている – 各ディレクトリのファイルシステムを気にしない仮想ファイルシステムとは ext4 proc Virtual File System xfs Disk Disk /home /var /proc

Slide 16

Slide 16 text

16 ©SEGA • Overlay FS (コンテナ型仮想化でよく登場する) – コンテナ内で見えるファイルシステムとして使用 – ディレクトリを重ね合わせた状態を見せる仮想ファイルシステムとは F1 F2 F3 F2 Lower Upper F1 F3 F2 Merged

Slide 17

Slide 17 text

17 ©SEGA • Windows特有で使えるもの – Projected File System API – Cloud File API • ファイルの存在を見せること、データ本体を切り離すこと、を実現仮想ファイルシステムとは File Data File Data Data 本講演では、これらに対して仮想ファイルシステムと呼びます

Slide 18

Slide 18 text

18 ©SEGA • データ(ファイル)は – ユーザーによって必要な範囲が変わる – 全ファイルが必要なことは稀仮想ファイルシステムが効果的な理由 File1 File2 Data Data File3 Data File4 Data File1 File2 File3 Data File4 Data Data Data ユーザー１ユーザー２つかう分だけデータ実体があればよい！

Slide 19

Slide 19 text

19 ©SEGA • データ本体がない状態でも、必要になったら”自動”で取得仮想ファイルシステムが効果的な理由 File1 File2 Data Data File3 Data File4 Data ユーザー File5 File6 Data File7 Data File8 Data Data Data Data Data 全てが揃っているように見えて、必要な分だけのデータでストレージ消費を最小化アクセスの瞬間で中身を取得 (実体化)

Slide 20

Slide 20 text

ProjFSとSlimSync

Slide 21

Slide 21 text

21 ©SEGA • ProjFS を採用 – ファイル/ディレクトリの外観が使用前後で変化しない – 安定した環境ならProjFSは高速 ProjFS と Cloud File API OS標準速度異常状態への対応その他 ProjFS 〇 ◎ × GVFS(Git Virtual File System)は ProjFS の先祖 C#ラッパーがある Cloud File API 〇 ▲ 〇クラウドストレージに対応した仮想ファイル機能を提供

Slide 22

Slide 22 text

22 ©SEGA • Windows10 (1803) にてProjFSの可能性を予見(動作をチェック済) – https://learn.microsoft.com/ja-jp/windows/win32/projfs/projected-file-system • Virtual Sync: Terabytes on Demand (GDC2022 / Bungie, Inc) 講演 – https://www.gdcvault.com/play/1027699/Virtual-Sync-Terabytes-on • 『NGS』開発チームと前述の講演をきっかけに協力体制 ProjFS採用の理由

Slide 23

Slide 23 text

23 ©SEGA • Git Virtual File System: GVFS – 2018年ごろに話題 – Team Foundation , Azure DevOps Server が必要 – 現在は “VFS for Git” (ただしメンテナンスモード) 余談

Slide 24

Slide 24 text

24 ©SEGA User Mode Kernel Mode 初期化: PrjStartVirtualizing() • 仮想化を開始するパスを設定 • 各処理のコールバックを登録 ProjFS APIの使い方指定フォルダー配下の特定 I/O 要求のみ転送 D:¥my-project¥ ProjFS [Provider] StartEnumeration GetPlaceholderInfo GetFileData : ProjFS [System] StartEnumeration GetPlaceholderInfo GetFileData :

Slide 25

Slide 25 text

25 ©SEGA User Mode Kernel Mode 初期化: PrjStartVirtualizing() • 仮想化を開始するパスを設定 • 各処理のコールバックを登録 ProjFS APIの使い方指定フォルダー配下の特定 I/O 要求のみ転送 D:¥my-project¥ ProjFS [Provider] StartEnumeration GetPlaceholderInfo GetFileData : ProjFS [System] StartEnumeration GetPlaceholderInfo GetFileData : PrjFillDirEntryBuffer() PrjWritePlaceholderInfo () PrjWriteFileData()

Slide 26

Slide 26 text

26 ©SEGA • ProjFS制御下では、ファイルは以下の状態を遷移ファイルの状態変化項目がDisk上にない. アイテム列挙に出現 FindFirstFile, readdir など項目はDisk上に存在. メタデータのみで、ファイル内容はカラオープン操作 CreateFile, fopen など項目はDisk上に存在. ファイル内容がストレージ上に存在. 読み取り操作 ReadFile, fread など Hydratedな状態からファイル内容が変更書込み操作 WriteFile, fwrite など Virtual Placeholder open read Hydrated Full

Slide 27

Slide 27 text

27 ©SEGA • ProjFS制御下では、ファイルは以下の状態を遷移ファイルの状態変化 Virtual Placeholder Hydrated Full open 仮想状態実体化ストレージを消費する範囲項目がDisk上にない. アイテム列挙に出現項目はDisk上に存在. メタデータのみで、ファイル内容はカラ項目はDisk上に存在. ファイル内容がストレージ上に存在. Hydratedな状態からファイル内容が変更 read write

Slide 28

Slide 28 text

28 ©SEGA ProjFS の舞台裏を紹介～技術的興味を持った皆様へ～

Slide 29

Slide 29 text

29 ©SEGA User Mode Kernel Mode • ドライバ間に、フィルタドライバーが挿入可能 – ProjFSはフィルタドライバーの1種 • ProjFSを使うとユーザーモードのプログラムとして実装 ProjFSの仕組み ProjFS ドライバー NTFS ファイルシステムドライバーエクスプローラーなどランタイムライブラリファイルシステムドライバーストレージクラスドライバー HDD/SSD ProjFSを利用した実装・列挙情報・ファイル内容操作 .... Callback I/Oリクエストデータ

Slide 30

Slide 30 text

30 ©SEGA ProjFSの仕組み (例:リポジトリ投影) Callback ProjFS ドライバー NTFS ファイルシステムドライバーエクスプローラーなどランタイムライブラリファイルシステムドライバーストレージクラスドライバー HDD/SSD project/ • main/ • Readme.txt ストレージより project/ • branch-a/ • License.txt リポジトリ情報より上層に見せる情報を収集投影元へのアクセスなど project/ • branch-a/ • License.txt • main/ • Readme.txt ProjFS マージ結果

Slide 31

Slide 31 text

31 ©SEGA さらに深いところへ～ファイルシステム NTFS の詳細へ～

Slide 32

Slide 32 text

32 ©SEGA • ProjFSは NTFS (NT File System)の機能を活用 – リパースポイント (再解析ポイント) • シンボリックリンクやジャンクションなど – ファイルやフォルダを区別しないエントリ形式 ProjFSの仕組み (下位ファイルシステム側) ※ リパースポイントがキー要素なので、ReFSでも使用可能

Slide 33

Slide 33 text

33 ©SEGA • 一般的なファイルの格納状態 ProjFSの仕組み (下位ファイルシステム側) HEADER MFT $MFT $MFTMirr ... File File MFTエントリ情報ファイルエントリ情報 Attr: $STANDARD_INFORMATION Attr: $FILE_NAME Attr: $DATA (Non-Resident) Cluster: File Data Cluster: File Data Cluster: File Data Data Run List Disk / Volume Volume内クラスタを示すファイル内容

Slide 34

Slide 34 text

34 ©SEGA • リパースポイントがある場合 (IO_REPARSE_TAG_PROJFS) ProjFSの仕組み (下位ファイルシステム側) HEADER MFT $MFT $MFTMirr ... File File MFTエントリ情報ファイルエントリ情報 Attr: $STANDARD_INFORMATION Attr: $FILE_NAME Attr: $REPARSE_POINT Disk / Volume Attr: $DATA (Non-Resident) Data Run List 実体化のタイミングで構成 Cluster: File Data Cluster: File Data Cluster: File Data ファイル内容 Data Run List

Slide 35

Slide 35 text

35 ©SEGA 低レイヤーな話はここまで。本編に戻ります

Slide 36

Slide 36 text

36 ©SEGA • ProjFSを使用したSlimSyncというツールを開発 – バージョン管理システム Perforce と接続 – 開発言語はC#を用いて実装 • ProjFS APIはWin32API • C#によるラッパーライブラリを使用 – GDC2022講演でも触れられていたMicrosoft製 – https://github.com/microsoft/ProjFS-Managed-API 設計事例現在は”Helix Core” 講演内は馴染み深い Perforce で表記

Slide 37

Slide 37 text

37 ©SEGA • ツールはサーバー・クライアント型の実装 – ProjFSを制御するファイルシステムプロバイダ – ユーザー操作を担当するクライアント • リポジトリ(ディポ)との同期、状態の変更など SlimSync SlimSync (ファイルシステムプロバイダ) SlimSync (クライアント) gRPC ProjFS

Slide 38

Slide 38 text

38 ©SEGA • ローカルのリポジトリ操作に専用ツール(SlimSyncクライアント)が必要 – バージョン管理ツールに備わる標準ツールではファイル自体が取得されてしまう – 同期操作によって、「ファイルは既にある状態」に見せかけたい SlimSync p4.exe, git.exe, svn.exe,...

Slide 39

Slide 39 text

39 ©SEGA Repository Backend SlimSync構造図 (ファイルシステムプロバイダ側) SlimSync Main [SYSTEM] File Request Perforceアダプター Perforce (Depot) ProjFS Callback処理部他リポジトリ用アダプター Repository Web Server (Kestrel) Client Web Debug Console Debug gRPC 制御 gRPC

Slide 40

Slide 40 text

『PSO2 ニュージェネシス』開発環境での効果

Slide 41

Slide 41 text

42 ©SEGA 『ファンタシースターオンライン2』(=PSO2)とは 2012年7月にサービス開始されたセガのオンラインアクションRPG 「無限の冒険」「オンラインRPG最高峰のアクション」「究極のキャラクタークリエイト」「境界を超えるRPG」をコンセプトに長期運営（今年で12周年!) 2021年6月にグラフィックエンジンを一新し、大幅リニューアルしたのが、『ファンタシースターオンライン2 ニュージェネシス』(=NGS) 超大型アップデートにより『PSO2』から1000年後の世界をオープンフィールドで実現。『PSO2』の世界はそのままプレイ可能で、セーブデータも共有し同じキャラクターで、『PSO2』と『NGS』の世界を自由に行き来できるのが最大の特徴。【対応プラットフォーム】PC、PS4、Xbox One、Switch(クラウド) 『PSO2 ニュージェネシス』とは?

Slide 42

Slide 42 text

43 ©SEGA • バージョン管理システム: Perforce(Helix Core) • ストレージ: HDD 6TB SSD 2TB 『NGS』の環境情報

Slide 43

Slide 43 text

44 ©SEGA • 既に運用中のタイトル – 開発に影響がでる変化はNG • 仮想ファイルシステム(ProjFS)は開発PCごとに使用の有無が設定可能 – チーム全体への影響が極めて少ない – 開発PC上で動作するので、 Perforceサーバー側の変更不要 – JenkinsエージェントをSlimSyncに置き換えて検証『NGS』で検証するにあたって

Slide 44

Slide 44 text

45 ©SEGA • 1ブランチのデータ量 – 全体 ▪ 1.09TB – コード ▪ 約50,000ファイル – アセット ▪ 約1,200,000ファイル ▪ 約800GByte 『NGS』のブランチ戦略

Slide 45

Slide 45 text

46 ©SEGA • 2ヵ月の間隔でリリースのためブランチ • 最大で5ブランチ並行しての作業 1TB * 5ブランチ = 5TB 『NGS』のブランチ戦略

Slide 46

Slide 46 text

47 ©SEGA • 新規取得からビルド完了までの時間 • ビルド後に実体化されたファイルを調査検証①アプリケーションのビルドへの効果リポジトリ全体投影されたファイル(メタデータのみが存在) 実体化されたファイル (ファイル内容がストレージ上に存在) ローカルファイル中間成果物等 SlimSync無効の場合のサイズ SlimSync有効の場合のサイズ

Slide 47

Slide 47 text

48 ©SEGA • 新規取得から実行した場合検証①アプリケーションのビルドへの効果 SlimSync 有無リボジトリの同期ビルド時間合計時間ストレージ使用量無効 2:55:40 0:22:41 3:18:21 1067.2GiB 有効 0:20:48 1:01:55 1:22:43 1.18GiB

Slide 48

Slide 48 text

49 ©SEGA • 差分取得を行ってから実行した場合検証①アプリケーションのビルドへの効果 SlimSync 有無リボジトリの同期ビルド時間合計時間ストレージ使用量無効 0:00:41 0:18:58 0:19:39 1067.2GiB 有効 0:00:12 0:20:53 0:21:05 1.18GiB

Slide 49

Slide 49 text

50 ©SEGA • オンデマンドのため、時間の掛かり方が変化リポジトリ同期のコストに対する補足 sync begin sync end Perforce FILE1 転送 FILE1 保存 FILE2 転送 FILE2 保存 FILE3 転送 FILE3 保存 FILE2 open FILE2 read sync begin sync end slimsync FILE2 転送 FILE2 保存 FILE2 open FILE2 read リビジョン管理リビジョン管理メリット: sync end までが速いデメリット: open から read までが遅い(※) メリット: 転送量が少ないメリット: 占有量が少ない

Slide 50

Slide 50 text

51 ©SEGA • ワークスペースマッピングの利用 SlimSyncを使用していない環境でもストレージ容量削減のため Perforceのワークスペースマッピングで取得ファイルを制限検証②ストレージの使用量について

Slide 51

Slide 51 text

52 ©SEGA • ワークスペースマッピングとは o ディポファイルを取得する際に保存されるワークスペース内の場所を指定可能 o ビューから除外することも可能 o 除外されたファイルはフォルダごと同期した場合も取得されなくなる検証②ストレージの使用量について

Slide 52

Slide 52 text

53 ©SEGA • ワークスペースマッピングの設定方法 o 1行につき1つのマッピングで構成 o フォルダ単位での除外やファイルの除外 o ディポシンタックスに一致するファイルの除外検証②ストレージの使用量について //depot/... //work/... -//depot/main/... //work/main/... //depot/main/source/... //work/main/source/... //depot/main/data/... //work/main/data/... //depot/main/asset/....json //work/main/asset/....json ※実際に使用されている設定とは異なります。

Slide 53

Slide 53 text

54 ©SEGA • ワークスペースマッピングは用途に合わせて2種類用意 – パッケージビルド用 • パッケージ作成に必要なソースファイルとデータファイルのみを取得 – アセットビルド用 • アセットをデータに変換するためにアセットを全て取得検証②ストレージの使用量について

Slide 54

Slide 54 text

55 ©SEGA • パッケージビルドマシンのストレージ使用量 • ワークスペースマッピングでは完全に制限することが難しい – フォルダ単位で制限しているため必要としているフォルダに不要なファイルが含まれている検証②ストレージの使用量について SlimSync有無使用量ブランチ全体に対する割合無効 250GiB 23% 有効 129GiB 12%

Slide 55

Slide 55 text

56 ©SEGA • アセットビルドマシンのストレージ使用量 • アセットの特徴 – 最新のブランチで使用するアセットは限られている • 『PSO2』のアセットで直近5ブランチで使用されたファイルは100MB未満 – バージョンごとに分かれておらず、新旧のデータが入り乱れている – 古いアセットも再利用や不具合修正のため必要になることがある検証②ストレージの使用量について SlimSync有無使用量ブランチ全体に対する割合無効 1045.72GiB 98% 有効 167.3GiB 15%

Slide 56

Slide 56 text

57 ©SEGA • SSD運用が可能。 1ブランチが200GB未満に抑えられたことで HDDからSSDへと切り替えることが可能になった。結果としてビルド時間の高速化が実現。仮想化による効果の度合い

Slide 57

Slide 57 text

58 ©SEGA • 仮想化による効果がでるケース/でないケース – 仮想化による恩恵は、「使用するファイルが分散している」場合に大きくなる。 – 「ファイル全てを必要とする」場合は効果が見込めない。考察仮想化による効果の度合い

Slide 58

Slide 58 text

59 ©SEGA • 仮想による効果が大きいケース考察仮想化による効果の度合いアクセスする対象が別 (フォルダ/ファイル) 1つのフォルダ内にデザイナ用/プログラマ用が混在していてもOK ※フォルダの構成はプロジェクトのものと無関係です

Slide 59

Slide 59 text

60 ©SEGA • 仮想による効果がでにくいケース – キレイにリポジトリが分離されている状態職種の中でも担当によって不要なファイルは存在しているため一定の効果は見込めます。考察仮想化による効果の度合い ※フォルダの構成はプロジェクトのものと無関係です

Slide 60

Slide 60 text

61 ©SEGA • 仮想による効果がでないケース考察仮想化による効果の度合いエンジンが配下の全てのファイルを読取ってしまう ※フォルダの構成はプロジェクトのものと無関係です

Slide 61

Slide 61 text

62 ©SEGA • 仮想化によって効率的になる部分があった – 作業始めの時間は明らかに短縮 – ストレージの実質的な使用量は削減 • 環境によっては効果が出せないケースも存在している – 使用しているエンジンやツールとの相性 – 役割ごとに綺麗にファイルが分けられている場合 • ワークスペースマッピングによる制限が不要になる – 細かなマッピングが不要になり設定する労力の削減や設定ミスにる不具合の防止が可能検証まとめ

Slide 62

Slide 62 text

ProjFS の組み込み TIPS ～起こった問題、その対策～

Slide 63

Slide 63 text

Slide 64

Slide 64 text

65 ©SEGA Perforce によるエンコーディング変換の概略事象: ファイル末尾が欠落する知識 TXT Perforce リポジトリサーバーデータベース TXT クライアントワークスペースクライアント設定（エンコーディング指定）クライアントファイルタイプとクライアント設定に応じた文字コード・改行コードエンコーディング変換（ファイルサイズ増大）ローカルストレージリポジトリ/ディポファイルはすべて↓で保存 • 文字コード＝UTF8 固定 • 改行コード＝LF 固定ファイルタイプ（エンコーディング指定） UTF8/LF SJIS/CRLF SlimSync ツール

Slide 65

Slide 65 text

66 ©SEGA 原因はファイルサイズの認識のズレ対応策 • VCS 側のエンコーディング変換機能を回避 • ファイルオープン時に先行取得してサイズ確定 ↓ 事象: ファイル末尾が欠落する対策 Virtual Placeholder Hydrated open read Full write フォルダー列挙ファイルオープンファイルリードバイナリファイル時 p4 dirs （何もしない） p4 print テキストファイル時 p4 dirs p4 print p4 print

Slide 66

Slide 66 text

Slide 67

Slide 67 text

68 ©SEGA IDisposable インターフェース事象: ファイルの先頭が破損する知識 using (FileStream fs = File.Create("README")) { AddText(fs, "Hello."); } FileStream fs = File.Create("README"); AddText(fs, "Hello.");

Slide 68

Slide 68 text

69 ©SEGA 原因は初歩的なリソースリーク事象: ファイルの先頭が破損する対策 using (var content = _virtualizationInstance.CreateWriteBuffer(length)) { GetFileContent(...); hr = _virtualizationInstance.WriteFileData(...); } var content = _virtualizationInstance.CreateWriteBuffer(length); GetFileContent(...); hr = _virtualizationInstance.WriteFileData(...); 実体は IWriteBuffer でこれは IDisposable

Slide 69

Slide 69 text

Slide 70

Slide 70 text

71 ©SEGA ProjFS におけるテーブルマージのルール事象: 大文字/小文字が正しくない知識 ProjFS ドライバー NTFS ファイルシステムドライバーエクスプローラーなどランタイムライブラリファイルシステムドライバーストレージクラスドライバー HDD/SSD my-project/ • main/ • Readme.txt ストレージより my-project/ • MAIN/ • License.txt プロバイダより my-project/ • main/ or MAIN/? • License.txt • Readme.txt ProjFS マージ結果微妙に違う… どうなる…？

Slide 71

Slide 71 text

72 ©SEGA 原因は ”正しい”エントリー名の規定の不足事象: 大文字/小文字が正しくない対策リポジトリサーバー SlimSync ツールクライアント "D:¥my-project¥Main¥dev¥UEproject¥fpsgame" "D:¥my-project¥main¥dev¥ueproject¥FPSGame" リポジトリ情報を参考にパスを正規化するデータベース

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

76 ©SEGA 原因は遅延ローディングとパス解決によるデッドロック対策案 • 遅延ローディングの徹底排除 • SlimSync ツールからのワークスペース参照禁止事象: OS が不安定になる対策 DLL 起動 DLL DLL をサーチ未ロード仮想化開始！アクセスパス解決遅延ロード DLL 未ロードのまま

Slide 76

Slide 76 text

Slide 77

Slide 77 text

78 ©SEGA 独自のコンテンツキャッシュ仕様 • 初見のファイルはキャッシュフォルダーに溜め込む • ファイル名はリポジトリハッシュから一意に決定今回実装したロジック事象: 作業途中で進行停止する知識キャッシュの存在確認コンテンツ取得キャッシュ Read キャッシュ Read キャッシュ Write : キャッシュヒット時 : キャッシュミス時

Slide 78

Slide 78 text

79 ©SEGA 事象: 作業途中で進行停止する知識存在確認取得 Read Write １つめのスレッド: （キャッシュミス）存在確認取得 Read Write ２つめのスレッド: （キャッシュミス） Read 存在確認３つめのスレッド: （キャッシュヒット）オープンエラー／オープン時にデッドロック書き込み先フォルダーに同名ファイルがある ↓ 暗黙の DeleteFile() が発生

Slide 79

Slide 79 text

80 ©SEGA 原因はマルチスレッド対応での排他ロック不足 C# ではアノテーションが利用可能事象: 作業途中で進行停止する対策キャッシュの存在確認コンテンツ取得キャッシュ Read キャッシュ Read キャッシュ Write GetFileContentCache(): 再入 NG [MethodImpl(MethodImplOptions.Synchronized)] public bool GetFileContentCache(...) {

Slide 80

Slide 80 text

81 ©SEGA 事象: ファイルオープンに失敗する課題コンパイル問題なし！ SlimSync ツールにツール自身からのアクセスが到達してる… デッドロック回避処理による File Not Found だ… SlimSync ツールは直接ファイルアクセスしない設計なのに…？？？

Slide 81

Slide 81 text

82 ©SEGA パスを扱う “Path” クラス事象: ファイルオープンに失敗する知識 string path1 = @"mydir"; string path2 = @"¥mydir"; string fullPath; fullPath = Path.GetFullPath(path1); Console.WriteLine("GetFullPath() returns ‘{0}'", fullPath); // GetFullPath() returns 'C:¥temp¥Demo¥mydir’ fullPath = Path.GetFullPath(path2); Console.WriteLine("GetFullPath() returns ‘{0}'", fullPath); // GetFullPath() returns 'C:¥mydir' string path1 = "C:/Program Files/Common Files"; string path2 = "C:/Program Files/Microsoft"; string relPath; relPath = Path.GetRelativePath(path1, path2); Console.WriteLine("GetRelativePath() returns ‘{0}’”, relPath); // GetRelativePath() returns ‘../Microsoft’ Path.GetFullPath() Path.GetRelativePath()

Slide 82

Slide 82 text

83 ©SEGA Windows ファイルシステムの古い仕様（8.3 形式）事象: ファイルオープンに失敗する知識 Path クラスは短縮ファイル名にも対応している一部メソッドは短縮ファイル名を展開するその際、ディレクトリエントリーを読み出す短縮ファイル名を持つエントリー

Slide 83

Slide 83 text

84 ©SEGA 原因は Path クラスによる短縮ファイル名の展開の試行対応策 • ~ 記号を含まないルールでのリポジトリ運用 • Path クラスのクローン実装による代替（特に下記） GetFullPath() GetRelativePath() 事象: ファイルオープンに失敗する対策

Slide 84

Slide 84 text

Slide 85

Slide 85 text

まとめ