SMB共有経由でコピーした後にファイルのチェックサムが変わる原因は何ですか？
SMBは通常、ファイルのバイト列を変更せずに転送します。そのため、チェックサムが一致しない場合は、比較対象の内容が変更されたか、一貫性なく読み取られたか、同じデータストリームではなかったことを意味します。
不一致は、アプリケーションが書き込みを完了する前にソースをハッシュ化した、片方でリソースフォークまたは代替ストリームを比較した、メディアアプリケーションやセキュリティアプリケーションが保存先を書き換えた、古いクライアントキャッシュを介して読み取った、またはストレージや転送のエラーが発生したことが原因で起こる場合があります。正しいテストでは、ソースを固定し、同じツールとモードで両方のファイルをハッシュ化し、SMB自体を原因と決めつける前に、管理された経路で転送を繰り返します。
両方のチェックサムが同じファイルデータを対象としていることを確認する
正確なソースパス、保存先パス、ハッシュ化コマンド、アルゴリズム、バイナリまたはテキストモード、各チェックサムの生成時刻を記録します。どちらのコマンドも、ショートカット、シンボリックリンクのリンク先、一時ファイル、サイドカーを読み取っていないことを確認します。
SHA-256ユーティリティは、指定したファイルから読み取ったバイト列を基にダイジェストを計算します。sha256sumのリファレンスを使えば、両方のエンドポイントで同じアルゴリズムと呼び出し方法を使用できます。
サイズが異なる場合は、ハッシュを比較する前に、不完全なコピーまたは変更されたコピーを調査します。サイズが同じでハッシュが異なる場合は、ソースの安定性、ストリームの範囲、ストレージからの読み取り、保存先での変更を引き続き確認します。
コピー中にソースを変更する可能性のあるアプリケーションを停止する
データベース、ダウンロードクライアント、仮想マシン、メディアエディター、同期ツール、その他ソースファイルに書き込むアプリケーションを停止します。ファイルを閉じた後にのみ、ソースのチェックサムを新しく生成します。
Rsyncのドキュメントでは、監視対象のソースディレクトリにファイルを移動するのは、完全に書き込みが終わってからにすべきだと説明しています。これは、変更中のソースファイルは一貫性なく転送される可能性があるためです。
SMBコピーの直前と直後に、ソースのチェックサムを比較します。2つのソースハッシュが異なる場合、最初に疑うべき原因はSMBではありません。テスト中にソースが変更されています。
Oplock、ローカル書き込み、キャッシュされたファイル状態を確認する
ソースと保存先にアクセスしている、開かれたSMBハンドルとローカルプロセスを一覧表示します。同じ共有に対して、SMB経由とNASホスト上での直接操作の両方から同時に書き込んでいる場合は、特に注意してください。
Sambaでは、opportunistic lockによってクライアントがファイルの変更をローカルにキャッシュし、必要に応じてサーバーへ同期できると説明しています。そのロックとoplockのモデルから、整合性テスト中はローカルとSMBの同時書き込みを制御すべき理由が分かります。
最初の対応として、サーバー全体でoplockを無効にしないでください。競合しているアプリケーションを終了し、新しいセッションを開いて、1つのファイルコピーを繰り返し、同時実行が関係していたかどうかを確認します。
ファイル内容と拡張属性・代替ストリームを分けて考える
想定するチェックサムがメインファイルデータだけを対象とするのか、それともリソースフォーク、拡張属性、代替ストリーム、ACL、メタデータも含むアーカイブを対象とするのかを決めます。両方で同じ範囲を使用してください。
ArchWikiでは、拡張属性を通常のファイル内容とは別に保存されるメタデータと説明しています。そのメタデータが失われたり変換されたりすると、メインデータストリームのチェックサムを変更しなくても、アーカイブやパッケージのハッシュが変わることがあります。
macOSのファイルでは、メインデータフォークをリソースフォークやAppleDoubleサイドカーとは分けて比較します。メタデータの不一致を、主要なファイルバイト列が変更された証拠と解釈しないでください。
再開とログに対応したコピー ツールを使用する
既知のコピー方法を1つ選び、新しい保存先ファイル名で転送を繰り返します。ファイルブラウザーの進行状況ダイアログだけに頼らず、再試行、再開、スキップ、失敗のログを保存してください。
MicrosoftはSMBを、アプリケーションがリモートファイルの読み取り、作成、更新を行えるプロトコルと定義しています。そのSMBファイルアクセスモデルから、チェックサムの変化は、プロトコルで想定される変換ではなく、データ経路または書き込み元の問題として扱えます。
ドラッグアンドドロップでは一致せず、ログ付きのコマンドラインコピーでは一致する場合は、SMBサーバーを変更するのではなく、アプリケーション、再試行動作、不完全ファイルの処理、ウイルス対策スキャン、コピー後の処理を比較します。
インデクサーやアプリケーションが書き換える前に保存先を比較する
コピー直後、ファイルを閉じた状態で、メディアスキャナー、ドキュメント変換ツール、写真管理アプリ、ウイルス対策ツール、同期クライアントが変更を加える前に保存先をハッシュ化します。
オレゴン州立大学のRobocopyガイドでは、ログ記録と再開に対応したコピーを重視しています。これにより、転送の完了と、その後にアプリケーションが保存先へアクセスする時点を明確に分けられます。
コピー直後の保存先ハッシュは一致するのに、後から変化する場合は、最初にファイルを書き込み用に開いたプロセスを特定します。恒久的な対策は、そのアプリケーションのメタデータ、最適化、または同期動作に対して行うべきです。
ストレージとネットワークの境界をまたいでテストを繰り返す
同じ閉じたテストファイルを、ソースNAS上でローカルに、保存先ファイルシステム上でローカルに、別のクライアントからSMB経由で、そして元のクライアントからコピーします。各段階の後にハッシュを計算します。
ZimaSpaceのNAS移行メタデータの保持ガイドでは、関連するルールとして、内容のハッシュとメタデータ項目を別々の受け入れ基準として検証する必要があると説明しています。
閉じたソースファイルのハッシュが繰り返しのコピーで一致し、コピー後のサービスが動作した後も変更されなければ、問題は解決しています。1台のディスク、コントローラー、クライアント、または再現性のあるファイルオフセットに不一致が追従する場合は、移行を停止してソースを保護してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
