クラウドや仮想環境の普及が進むなか、Windows Server上で大きなファイルを扱う機会が増えています。効率的なデータ転送を図るために導入されたODX（Offloaded Data Transfer）やCopy Offload機能ですが、設定を整えてもなかなか動作しないといった声も聞かれます。この記事では、SMB共有上でODXが動かない原因と、その解決策を多角的に探ります。
ODX/Copy Offload機能とは
ODX（Offloaded Data Transfer）は、Windowsのサーバーやクライアント側のファイル転送負荷を軽減するために実装された機能です。通常はファイルの読み込みと書き込みをクライアント側で行いますが、ODXを使うことでストレージ装置間で直接データをやり取りし、データ転送を高速化します。いわゆる「トークンベース」の手法であり、以下のようなメリットがあります。
- 大容量データの転送時間を短縮できる
- クライアントやサーバーのCPU負荷を軽減できる
- ネットワーク帯域の消費を削減できる
Copy Offload機能は、SMB経由でのファイル転送にも類似のオフロード概念を導入しており、実質的にODXと同等の手法で転送作業を最適化します。しかし、環境によってはこれらの機能が思うように動かず、CopyChunkにフォールバックしてしまうケースがあります。
ODXが動作しない原因の主なポイント
ODXが機能しない原因は多岐にわたります。ハードウェア構成やレジストリ設定、サードパーティーソフトウェアの影響など、さまざまな要因を総合的に確認することが重要です。ここでは主に以下のような可能性を考慮します。
1. レジストリ設定の不備
Windowsのレジストリには、ODXの有効・無効を制御する設定が存在します。HKLM:\System\CurrentControlSet\Control\FileSystem の FilterSupportedFeaturesMode は、0に設定されていることが望ましいとされています。0以外の値に設定されていると、ODXが制限される可能性があります。
さらに、FilterSupportedFeauresMode 以外にも、ODX関連のレジストリ値が知らないうちに変更されている場合もあります。たとえば、下記のようなレジストリを再度見直してみてください。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\<StorPortまたはミニポートドライバ名>\Parameters
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies環境によってキーや値の名称は異なる場合があるため、最新のドキュメントを参照しつつ確認することが大切です。
2. フィルタドライバの干渉
ウイルス対策ソフトウェア、サードパーティー製のバックアップソフト、暗号化ソフトなどがインストールされている場合、それらのフィルタドライバがODXのオフロード動作を阻害する場合があります。fltmc instances コマンドを使って、フィルタドライバの一覧と動作状態をチェックするとトラブルシュートに役立ちます。
fltmc instances上記のコマンド出力において、0xf（オフロード読み取り・書き込みが有効）になっているかどうかを確認しましょう。もし異なる値や、特定のフィルタドライバが疑わしい場合は、そのフィルタドライバをアンロードして再度検証を行うことも手段の一つです。
3. SMB共有やストレージ設定の問題
SMB共有のプロトコルバージョンが古い場合や、ストレージ側（NetApp ONTAPなど）の設定が不十分な場合にもODXは機能しません。NetApp ONTAPを使うケースでは、以下の点を改めて確認しましょう。
- ONTAPのバージョン（9.11.1P13など）がODXをサポートしているか
- SMB共有の設定でCopy OffloadやODX関連のオプションが無効化されていないか
- ライセンスやオプションでODXがカバーされる構成になっているか
また、SMB 3.0以降を利用していることが前提となる場合もあります。クライアントとサーバー双方のSMBバージョンが合っていないと、予想外の動作になることがあります。
4. ネットワークドライバやHBAドライバのバージョン不一致
ODXやCopy Offloadは、最終的にストレージハードウェアへ転送を委譲します。その際に、ネットワークインタフェースカード（NIC）やHBA（Host Bus Adapter）のドライバが古いバージョンだと、機能が利用できない場合があります。ファームウェアやドライバに既知の不具合が報告されていないか、メーカーのリリースノートをチェックするようにしましょう。
5. クライアントの自動フォールバック動作
ODXを試みても何らかの障害があった場合、Windowsは自動的にCopyChunk（通常のSMBファイル操作）にフォールバックします。たとえば、ODXの初期要求が失敗したり、トークン取得処理がうまくいかなかった場合です。クライアントがODXを使用しようとするかどうかは自動判断に依存しているため、特定のスイッチで「常にODXを使う」ようにすることは原則できません。
実際の設定例と確認手順
実際の設定やトラブルシュートを行う際に、次のような手順を踏むと原因特定に近づけます。
1. レジストリ値の確認
PowerShellやレジストリエディタを用いて、FilterSupportedFeaturesMode の値が0になっているかを確かめます。もし1や2など、0以外の値であれば0に変更したうえでサーバーを再起動し、挙動を再検証します。
reg query HKLM\System\CurrentControlSet\Control\FileSystem /v FilterSupportedFeaturesMode2. フィルタドライバの状態チェック
サードパーティー製のウイルス対策ソフトやバックアップソフトがインストールされている場合、スキャンやリアルタイム保護の対象から一時的に該当ボリュームを除外するテストを行うか、まったく別のテスト環境で同じ操作を試みるといった検証方法があります。
3. ストレージ側のODXサポート設定
NetApp ONTAPを例に挙げると、SMB共有に対して以下のようなオプションを設定できます。ONTAPのCLIやWebUIで、ODXに相当する機能が有効化されているかを再度確認します。ストレージメーカーによってコマンドやGUIが異なるため、各ベンダーの手順を参照してください。
vserver cifs options show表示されるオプションの中にOffloadなどのキーワードが含まれているかをチェックし、必要なら有効化します。NetAppの場合、storage efficient data transfer (SEDT)などの呼称で表現されている場合もあるため注意が必要です。
4. SMBトレースによる実際のコマンド分析
Windows環境でODXが実施されているかどうかを確認するには、SMBトレースを取得して実際のパケットを解析するのがもっとも確実です。Microsoft製のNetwork MonitorやMessage Analyzer、Wiresharkなどを使用し、以下の手順で確認します。
- トレース開始
- PowerShellで
netsh trace start capture=yes report=disabled scenario=FileSharing tracefile=C:\Temp\SMBTrace.etlのように開始するか、Wiresharkで対象ネットワークインターフェースを指定してキャプチャを開始。
- 大きめのファイルをコピー
- ODXが動作しやすいように、数GB～数十GBクラスのファイルをSMB共有間でコピー。
- トレース終了・解析
netsh trace stopあるいはWiresharkのキャプチャを停止し、保存したデータを解析。SMBのコマンドにFSCTL_OFFLOAD_READやFSCTL_OFFLOAD_WRITEが含まれているかどうかをチェック。
もしこれらのコマンドが出現せず、代わりにSMB2 WRITEやCOPYCHUNKのみが行われている場合は、ODXによるオフロード処理が行われていない可能性が高いです。
ODXを強制的に使う方法はあるのか
公式ドキュメント上、ODXを絶対的に「オン」にするスイッチは存在しないとされています。ODXは環境がすべて整っている場合に自動的に利用される設計です。つまり以下の条件が満たされていれば、原則としてODXが有効化されると考えられています。
- OSがODXに対応している（Windows Server 2012以降、Windows 10/11）
- ストレージがODXをサポートしている（NetApp、EMC、HPEなど最新のストレージ製品）
- レジストリ設定により無効化されていない（
FilterSupportedFeaturesMode=0など） - フィルタドライバやアンチウイルスによるブロックが行われていない
- SMB共有やネットワーク環境が正常に機能している
もしこれらをすべて満たしているはずなのに動作しない場合は、ファイルコピー時にエクスプローラ以外の手段を試す、あるいはバッチファイルやRobocopy、Xcopyなどでも動作状況をチェックしてみると状況を絞り込みやすいでしょう。
ODX動作を阻害しがちな要素を体系的にまとめた表
| 要素 | チェック内容 | 対応策 |
|---|---|---|
| レジストリ (FilterSupportedFeaturesMode) | 0以外の値になっていないか | 0に変更後サーバーを再起動する |
| フィルタドライバ (ウイルス対策など) | フィルタドライバがODX要求をブロックしていないか | 一時的に除外、またはアンロードしてからコピー動作を再テスト |
| ストレージ (NetApp ONTAPなど) | ODXまたはSEDT機能が有効かつライセンスがあるか | CLIやWebUIで機能を有効にし、バージョンやプロトコルの要件を満たす |
| SMB共有設定 | SMB 3.0以降が有効かつ、共有に設定上の制限がないか | 共有プロパティやグループポリシーで制限されていないかを確認 |
| ネットワークドライバやHBAドライバ | ドライバやファームウェアが古くODX関連の不具合が報告されていないか | 最新版に更新し、メーカーの既知の問題リストを確認 |
| トレース結果 (SMBパケット解析) | 実際にFSCTL_OFFLOAD_READ/WRITEがコマンドで発行されているか | WiresharkやNetwork Monitorでパケットを解析し、CopyChunkへのフォールバックが発生していないかを確認 |
具体的な検証シナリオと手順
ここでは、実際にODXが動作しない場合の検証方法を具体的に紹介します。
シナリオ1：ウイルス対策ソフトによる干渉を疑う
- まずは対象のサーバーかクライアントでウイルス対策ソフトを停止（リアルタイム保護のみ無効化）し、再度ファイルコピーを実施。
- 変化がない場合、サービスレベルではなく、ソフトウェア自体を完全に停止またはアンインストールできるテスト環境で再度試す。
- それでもODXが動作しない場合、他の要因を深掘りする。
シナリオ2：NetApp ONTAP側の設定を見直す
- ONTAP CLIでCIFSサーバーやvserverのオプションを確認。
vserver cifs options showやvserver cifs security showなどで詳細を把握。 - オフロード転送関連の機能を有効にする設定が存在する場合はオンにする（ONTAPバージョンによって設定項目の名称が異なる場合がある）。
- 必要に応じてNetAppサポートに問い合わせ、ONTAP側でODX関連の既知の問題やパッチ情報を入手する。
シナリオ3：プロトコルバージョンとSMB設定の整合性を再チェック
- クライアントがSMB 2.1やSMB 3.0を利用しているか、
Get-SmbConnectionコマンドで確認。 - サーバー側がSMB 3.1.1など最新バージョンで動作している場合は問題ないが、クライアントが古いOSなら強制的にダウングレードされる可能性もある。
- グループポリシーやローカルポリシーでSMBバージョンを制限していないかを確認する。
シナリオ4：物理ディスクのODXサポートをPowerShellで確認
Windows ServerやWindows 10/11のクライアントで下記コマンドを実行し、OperationalDetails にODXサポートが表示されるか確かめます。
Get-PhysicalDisk | Select-Object MediaType, OperationalStatus, OperationalDetailsもしOperationalDetailsにODX関連の情報がなかったり、サポート外の記述がある場合は、ドライブ側で何らかの理由でODXが無効化されている可能性があります。
それでも解決しない場合の手段
上記の手順を踏んでも解決に至らない場合、以下のサポートに問い合わせることで詳細な検証が可能です。
- Microsoftサポート：Windows OS側の問題を調査する場合
- ストレージベンダー（NetAppなど）のサポート：ONTAP側でODX実装に関するバグやアップデート情報を入手する場合
- ネットワーク機器ベンダー：NICやHBAのファームウェアの問題を疑う場合
実際の運用環境では、サポート同士の連携が必要になるケースも多いため、ログやトレースをしっかり記録しておくと説明がスムーズになります。
まとめ
ODXやCopy Offloadは、大容量データの転送効率を大幅に向上させる重要な機能です。しかし、Windowsやストレージ、ネットワーク、サードパーティーソフトなどのさまざまな要因によって動作が阻害されるケースも少なくありません。設定や環境を見直しつつSMBトレースなどで実際のコマンドが発行されているかどうかを確認すると、原因の絞り込みが進みやすくなります。
特にODXは「強制的にオンにする」ための設定が公式には用意されていないため、各種前提条件が正しく満たされているかを一つひとつ検証することが重要です。最終的にはベンダーやMicrosoftのサポートと連携し、環境全体の構成に問題がないかを包括的に調査するのが確実なアプローチでしょう。
コメント