## 定義 ブロックレベル差分同期とは、ファイル単位ではなくストレージブロック単位で変更を追跡し、変更されたブロックのみを転送することで大容量データの定期同期を効率化する手法である。rsync に代表される従来のチェックサムベースのファイル同期と対比される。(Source: [[@2013__LISA__dsync - Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data]]) ## ファイルレベル同期との比較 | 観点 | ファイルレベル同期（rsync 等） | ブロックレベル差分同期（dsync 等） | |---|---|---| | 変更検出タイミング | 事後（同期時にチェックサム計算） | オンライン（書き込み発生時にリアルタイム追跡） | | チェックサム計算 | 必要（同期のたびに全ブロックを読む） | 不要（追跡結果を直接参照） | | ディスク I/O | 高（変更検出のために全体スキャン） | 低（変更ブロックのみ読み取り） | | キャッシュ汚染 | 大（全体スキャンがページキャッシュを置換） | 小 | | CPU 使用率 | 高（チェックサム計算） | 低 | | 実装層 | ユーザー空間 | カーネル拡張（例: Linux 3.2.35） | ## 実装アプローチ dsync（Knauth & Fetzer, LISA13）の実装では： 1. **カーネル拡張**でブロックへの書き込みをフックし、ダーティビットマップを維持する 2. ユーザー空間のデーモンがビットマップを定期的に読み出し、変更済みブロックを転送する 3. 変更追跡はオンラインで継続するため、次の同期サイクルでは前回以降の差分のみを処理する ## 性能特性 - 同期時間: チェックサムベースより**最大 2 桁（100 倍）短縮**（合成・実ワークロード共） - データサイズが大きいほど相対的な優位性が拡大する（チェックサム計算のコストはデータ量に比例） ## 横断的知見 - (まだ 1 ソース。2 ソース目以降で横断観察を追記予定) ## 未解決の問い - クラッシュリカバリ時の一貫性保証はどのように実装するか（書き込み中クラッシュでビットマップと実データの乖離が生じた場合） - ブロックレベル追跡のオーバーヘッド（書き込みごとにフックが走る）は書き込み集約的なワークロードでどの程度になるか - LVM スナップショットや ZFS の CoW（コピーオンライト）と比較したとき、設計上の優位性・劣位性はどこか - コンテナ・仮想マシンのライブマイグレーション（メモリダーティページ追跡）と同様のパターンを持つか ## 関連 - [[@2013__LISA__dsync - Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data]] — ブロックレベル差分同期を Linux カーネル拡張として実装した研究 - [[ファイルレベル同期]] — ファイルレベル同期との対比概念。rsync 系の従来手法 - [[Thomas Knauth]] / [[Christof Fetzer]] — 考案者（TU Dresden） - 関連 MOC: [[SRE - MOC]] ## 出典 - [[@2013__LISA__dsync - Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data]]