なぜ拡張属性がNASのファイル移行を遅くするのか？

拡張属性は、それらを保持することで各ファイルに繰り返しのメタデータ処理が加わる場合、NASファイル移行を遅くすることがあります。属性は通常小さいですが、移行ツールはそれらを発見、読み取り、マッピング、送信、再作成、時には検証する必要があります。数千のファイルを含むディレクトリツリー全体で、そのオブジェクトごとの作業は、属性データがほとんどネットワークを通過しなくても目に見えるものになることがあります。

遅延は条件付きです。大量の小さなファイルは、xattrの有無にかかわらず、作成とカタログ化にすでにコストがかかります。プロトコルの遅延、ディレクトリの更新、権限、インデックス作成、ストレージI/O、アプリケーションの動作が同じ症状を引き起こすことがあります。したがって、拡張属性は移行コストの増分として測定されるべきであり、NASコピーが遅い唯一の理由と見なすべきではありません。

拡張属性はファイルコピーに何を追加するのか？

ファイルコピーは通常、ペイロードデータに加え、サイズ、タイムスタンプ、所有権、権限などの基本的なメタデータを含みます。拡張属性（一般にxattrと呼ばれる）は、ファイルやディレクトリに追加の名前と値のメタデータを付加します。Linuxはユーザーデータ、セキュリティラベル、信頼された属性、アクセス制御リストなどのシステムオブジェクト用に別々の名前空間を使用します。Linux拡張属性モデルは、ファイルシステムの制限が異なる場合があることも指摘しています。

保持にはペイロードのコピー以上の操作が必要な場合があります。ツールは属性名を列挙し、その値を取得し、宛先が各名前空間をサポートしているか判断し、新しいオブジェクトに許容される値を設定する必要があります。Linuxはリスト、読み取り、書き込みを異なるxattrシステムコールで提供しています。これはネットワークリクエストの固定数を証明するものではありませんが、属性処理が別の処理経路を持つことを示しています。

実際のコストは実装に依存します。クライアントはキャッシュ、パイプライン処理、結合、または操作のスキップを行うかもしれませんし、サーバーは属性をインラインまたは別のメタデータ構造に格納するかもしれません。重要な区別はバイト数とオブジェクト数の間にあります：属性は数バイトしか含まなくても、それを持つすべてのファイルに対して別の判断が必要になることがあります。

なぜファイル数は属性サイズより重要なのか？

50GBのファイル1つは主に長いペイロードストリームを持つ1つのオブジェクトです。同じ容量を写真、ドキュメント、ソースファイル、パッケージツリーに分割すると、数十万のオブジェクトが関与する可能性があります。各宛先オブジェクトは、オプションのメタデータ保持を考慮する前に作成され、ディレクトリに登録されなければなりません。

これにより2層のオーバーヘッドが生じます。基本的な小ファイル処理には、ファイルのオープン、レコードの割り当て、ディレクトリの更新、標準メタデータの設定、ハンドルのクローズが含まれます。xattrの保持は、その上に属性の列挙と再作成を追加する可能性があります。属性が翻訳や別の表現を必要とする場合、メタデータ経路はさらに増加します。ネットワークがほとんど追加の属性データを運んでいなくても、累積時間は増加することがあります。

その仕組みから普遍的なリクエストの乗数は導かれません。「属性ごとに4リクエスト」という主張は、正確なクライアント、プロトコルバージョン、転送ツール、サーバー構成のパケットトレースが必要です。したがって、1秒あたりの完了ファイル数やメタデータ操作の遅延の方が、属性サイズだけから結果を推定するよりも有用です。

プロトコルとファイルシステムの違いはいつ翻訳作業を増やすのか？

拡張属性には、普遍的なクロスプラットフォームの表現方法はありません。Linuxのファイルシステムはxattrの名前空間を公開し、Windowsのファイルシステムは名前付き代替データストリームを公開することがあり、ネットワークプロトコルは独自のオプション機能を定義しています。Microsoftは代替データストリームのサポートをファイルシステム機能として文書化しており、NFSv4はオプションのxattr拡張を通じて拡張属性を定義しています。

移行ツールは、それらの表現が一致しない場合にどうするかを選択しなければなりません。名前付きストリームを宛先のxattrにマッピングしたり、サポートされている名前空間のみを保持したり、プライベートエンコーディングを使用したり、別のオブジェクトを作成したり、メタデータを省略してエラーを報告したりすることがあります。例えば、Sambaのstreams xattrモジュールは、SMBの代替データストリームをPOSIX xattrsに格納できますが、これはすべてのSMB共有に対するルールではなく、設定されたサーバーの動作です。

互換性のための作業は、パフォーマンスコストが小さくても正確性に影響を与えることがあります。所有権、ACL、セキュリティラベル、またはアプリケーションのメタデータは、ペイロードデータのみをコピーする移行では保持されない場合があります。問題が低スループットではなくアクセス不能である場合は、別のNAS移行権限失敗のワークフローが適切なトラブルシューティング手順を提供します。これはxattrsが遅延の原因である証拠ではありません。

AppleDoubleはいつ追加のメタデータオブジェクトを作成するのか？

Macファイルはデータフォーク、リソースフォーク、Finder情報、その他のメタデータを含むことがある。宛先が完全なオブジェクトをネイティブに表現できない場合、AppleDoubleは2つのオブジェクト形式を提供する。AppleDouble形式定義は通常のデータフォークとリソースフォークや属性を運ぶヘッダファイルを分離する。

これにより、移行がドットアンダースコアファイルのような補助名を作成する場合がある理由が説明されるが、すべてのMacファイルがそれを生成するわけではない。追加オブジェクトはメタデータがその表現を必要とし、ソフトウェアパスがAppleDoubleを選択した場合にのみ関連する。最新のSambaサーバーはMac SMBメタデータモジュールやバックアップxattrやストリームも使用できるため、正確な結果はクライアントの動作、サーバー構成、ファイルシステムの能力に依存する。

補助オブジェクトはファイル作成、ディレクトリ、検索、インデックス作成、バックアップ作業を追加する可能性がある。これによりファイル数が倍増したりスループットが半減する保証はない。クロスプラットフォームの接続やアクセスの失敗も別の問題であり、WindowsとmacOSのSMB互換性のワークフローはメタデタ機構を理解した後に使用できる。

なぜすべての遅い移行がXattrの問題ではないのか？

オプション属性がなくても大規模な小ファイルツリーは遅いです。ファイル作成、ディレクトリロック、権限チェック、タイムスタンプ、ジャーナルコミット、ウイルススキャン、メディアインデックス、チェックサム、アプリケーションレベルの検証はすべて、1秒あたりに完了するファイル数を減らす可能性があります。HDDのシーク動作や同期メタデータ更新はストレージ遅延を増加させるかもしれませんが、xattrが原因であることを証明するものではありません。

クライアントとサーバーがオブジェクトレベルの操作を待っている間、ネットワークはアイドル状態に見えることもあります。そのパターンはxattr作業と互換性がありますが、通常のファイル作成、ディレクトリ競合、同期書き込みとも同様に互換性があります。したがって、CPU使用率と生のメガバイト毎秒だけでは不十分です。

最も明確な属性付与は制御された比較です。同じファイルセット、ソース、宛先、プロトコル、温度、ストレージ状態を使用し、メタデータを保持する実行とオプション属性を省略することが知られているコンテンツ重視の実行を比較します。その差はその環境における追加の保持コストを推定し、別のNASデバイスの普遍的なベンチマークにはなりません。

メタデータポリシーを変更する前に何を測定すべきか？

データセットから始めます。ファイルとディレクトリの数を数え、サイズ分布を調査し、実際にxattrを持つオブジェクトの数を特定し、どの名前空間やストリームタイプが現れるかを記録します。属性付きファイルが少数の移行は、アプリケーションメタデータ、ACL、またはセキュリティラベルが広範に付与されているソースツリーとは異なるリスクプロファイルを持ちます。

進行状況はバイト毎秒とファイル毎秒の両方で測定します。経過時間、メタデータ警告、宛先エラー、利用可能な場合はプロトコルトレース、CPU負荷、ストレージ遅延、付随ファイルの出現を記録します。これにより、ペイロードの帯域幅制限とオブジェクト処理制限が分離され、属性保持の変更による遅延の変化が示されます。

テストが速くなるからといってメタデータを削除しないでください。上流のrsyncは--xattrsまたは-Xでxattrの保持を可能にしますが、他のプラットフォームや古いバンドル版では異なるオプションの意味を持つ場合があります。rsyncのxattrオプションはインストールされているバージョンと照合する必要があります。パフォーマンス向上は、失われるACL、セキュリティコンテキスト、Finder情報、またはアプリケーション状態と比較して評価しなければなりません。

よくある質問

すべてのNASファイルに拡張属性がありますか？

いいえ。ファイルシステムはすべてのファイルがxattrを使っているわけではなくてもxattrをサポートする場合があります。あるファイルはユーザータグ、ACL、セキュリティラベル、リソース情報、アプリケーションメタデータを持ち、他のファイルは通常のファイル内容と基本的なメタデータのみを持ちます。ディレクトリ全体が属性付きと仮定するよりも、ソースを検査する方が信頼できます。

xattrがなくても小ファイルが遅いのはなぜですか？

各ファイルは依然として作成、ディレクトリの更新、権限、タイムスタンプ、割り当て、およびハンドル操作を必要とします。十分な数のオブジェクトがあると、これらの固定コストがペイロード転送を支配します。Xattrはさらに層を追加できますが、それを削除しても基礎となる小ファイルの作業負荷はなくなりません。

ドットアンダースコアファイルはAppleDoubleが遅延の原因であることを証明しますか？

いいえ。これらは関連するメタデータオブジェクトが存在することを示しており、AppleDouble関連の作業が合理的な仮説となります。これらはそのオブジェクトに費やされた時間を定量化せず、インデックス作成、基本ファイルの作成、ストレージの遅延、その他の移行コストを除外しません。

rsyncはデフォルトで拡張属性を保持しますか？

一般的な上流の動作ではありません。Xattrの保持には関連オプションが必要で、サポートされる名前空間は権限と宛先ファイルシステムに依存します。OSによって異なるrsyncバージョンが搭載されている可能性があるため、解釈前にローカルのマニュアルを確認してください。 -X, -Eまたはアーカイブモードの動作。

SMBからNFSに切り替えれば自動的に問題は解決しますか？

いいえ。両方のプロトコルには実装固有のメタデータ動作があり、NFSv4のxattrサポートはオプションです。プロトコルの選択には権限、クライアントの互換性、ロック、ワークロードの適合性も関わります。これらの広範なトレードオフは、xattrのみのパフォーマンス結論ではなく、別のSMB対NFSの比較に含まれます。

最終的な結論

拡張属性は、ファイルごとの読み取り、マッピング、書き込み、または関連オブジェクトが十分に増加して大規模になると、NASのファイル移行を遅くする可能性があります。メタデータポリシーを変更する前に、制御された測定で増分コストを確認し、通常の小ファイルのオーバーヘッド、プロトコルの動作、インデックス作成、権限、およびストレージの遅延を診断に含めてください。