なぜSMBファイルの変更はインクリメンタルインデクサーにバースト状に届くのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Do SMB File Changes Reach an Incremental Indexer in Bursts? - Zima Store Online

SMBファイルの変更は、書き込みや通知がキャッシュされ、まとめられ、キューに入れられ、複数の境界を越えて配信されるため、インクリメンタルインデクサーにバースト状に届くことがあります。

アプリケーションがファイルを継続的に保存していても、SMBクライアントがリースのもとで書き込みを保持し、サーバーがディレクトリの変更を記録し、ウォッチャーが長時間有効な通知リクエストを待機している場合があります。その後、インデクサーは重複イベントをデバウンスしたり、オーバーフロー後にディレクトリをスキャンしたり、再接続後に処理を再開したりします。各レイヤーは最終的な変更を保持しながら、個々のイベントが下流で可視化されるタイミングを変えます。

クライアントキャッシュによって保存時刻とサーバーからの可視化時刻が分離される

SMBのリースとオポチュニスティックロックにより、共有条件が許す場合、クライアントは読み取り、書き込み、またはハンドルをキャッシュできます。アプリケーションによる保存は、すべてのデータとメタデータがサーバーにフラッシュされる前に、ローカルキャッシュに対して完了することがあります。

MicrosoftによるSMBクライアントキャッシュの説明では、オポチュニスティックロックによって、サーバーとのアクセス調整を行いながらローカルバッファリングを可能にし、パフォーマンスを向上させるとされています。リースの解除やクローズによって、複数の変更がまとめてフラッシュされることがあります。この違いは、後の実環境テストでも確認できます。

エディターは、1回のインプレース書き込みではなく、一時ファイルへの保存、名前変更、置換操作を通じて保存することもあります。そのため、1回の人間の操作が複数のプロトコルイベントを生成する一方、短時間に行われた複数の編集が1つの最終的なサーバー状態に集約されることがあります。

CHANGE_NOTIFYは制限付きリクエストを通じてディレクトリのアクティビティを報告する

SMBウォッチャーはディレクトリに対してCHANGE_NOTIFYリクエストを発行し、サーバーが変更またはエラーを返すまで待機します。応答バッファには容量の上限があるため、アクティビティが急増すると満杯になり、クライアントはバッチを処理した後に別のリクエストを発行する必要があります。

SMB変更通知に関するSMBプロトコルのドキュメントでは、完了フィルター、出力バッファ、キャンセル、通知の動作が定義されています。これらの仕組みにより、個々の編集が完全にタイミングどおりに1件ずつ流れるのではなく、変更のリストとして自然に配信されます。自動化が後続処理を行う前に、中間結果を検査できる状態にしておく必要があります。

バッファがオーバーフローすると、ウォッチャーは変更が発生したことだけを認識し、ディレクトリを再スキャンする場合があります。切断と再接続によって、現在のファイルシステム状態から調整しなければならない別の未観測区間が生じます。この境界は、現実的な運用条件のもとで個別に測定する必要があります。

インデクサーは高コストな処理を意図的にデバウンスし、バッチ処理する

書き込みのたびに即座に解析すると、書き込み途中のファイルを読み込んだり、同じドキュメントを何度も埋め込んだりすることになります。インデクサーは一般に、一定の静穏期間を設け、パスの重複を排除し、並行処理数を制限し、データベースやベクトルインデックスへのコミットをバッチ処理します。複数のソースが限られたコンテキストを奪い合う場合、その実際の影響が現れます。

SMB通知の監視に関する運用ドキュメントでは、SMB2 CHANGE_NOTIFYリクエストをディレクトリ単位で監視し、解釈する方法が示されています。そのインターフェースの上位に置かれるインデクサーは、独自のスケジューリングと安定性のルールを選択します。この依存関係は、最終的なインターフェースに明示的に残す必要があります。

障害の境界は、バースト配信をデータ損失とみなすことです。すべての最終ファイルバージョンが鮮度目標の範囲内でインデックス化されるなら、バースト性は許容できます。名前変更の欠落、再スキャンを伴わないオーバーフロー、または恒久的に古いパスは正確性の障害であり、シーケンスを考慮した調整が必要です。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

SMBのフラッシュからインデックスのコミットまで、1つの編集を追跡する

作成、追記、名前変更、置換、削除の操作を、低速と高速の両方のレートでタイムスタンプ付きで生成します。アプリケーションの保存、クライアントのフラッシュ、サーバーのクローズ、リースの解除、CHANGE_NOTIFY応答、オーバーフロー、再接続、ウォッチャーキュー、デバウンス期限、パーサーの開始、コンテンツハッシュ、アクティブなインデックスコミットを記録します。

インクリメンタル変更キャプチャとイベント処理を比較します。通知のオーバーフローとネットワークの再接続を意図的に発生させ、その後、連続稼働時と同じ最終的なファイルシステム状態を調整処理が検出できることを確認します。そのため、結果は元の証拠と照合しなければなりません。

バーストによって最終状態の正確性が保たれ、宣言した鮮度ウィンドウを満たせば合格です。デバウンスとバッチサイズの調整は、クライアントのフラッシュ遅延、SMB通知遅延、再スキャン時間、インデクサーのバックプレッシャーを分離した後にのみ行います。ポーリングを高速化しても、壊れた調整経路を修復することはできません。