ODX / Copy‑Offload SMB NetApp ONTAP 9.11.1 : diagnostic Windows 10/11 et résolution

Vos copies SMB entre Windows 10/11 et NetApp ONTAP n’activent pas ODX ? Ce guide fournit une méthode pas‑à‑pas pour diagnostiquer, observer et lever les blocages afin que la copie « zero‑copy / token‑based » se déclenche réellement.

Sommaire

Fonction ODX / Copy‑Offload non utilisée lors des copies SMB

Vue d’ensemble de la question

Un administrateur constate que, lors de copies de fichiers entre des postes Windows 10/11 Pro et des partages SMB hébergés sur NetApp ONTAP 9.11.1 P13, les clients n’envoient pas de requêtes ODX (Offloaded Data Transfer) et retombent systématiquement sur la mécanique server‑side copy « CopyChunk ». Il souhaite :

un outil ou une méthode pour vérifier quelles commandes SMB sont réellement négociées ;
un moyen de « forcer » l’usage d’ODX ;
la confirmation que la configuration serveur/client est correcte (clé FilterSupportedFeaturesMode = 0, filtres FLT désactivés, etc.).

Comprendre ODX, CopyChunk et ce que Windows décide

ODX (Offloaded Data Transfer) permet au client SMB (Windows) d’ordonner au stockage de cloner les blocs côté baie à l’aide d’un token, au lieu de transiter les données par le réseau et la pile I/O du client. Sur le fil SMB, ODX se matérialise par des IOCTL FSCTL_OFFLOAD_READ et FSCTL_OFFLOAD_WRITE.

CopyChunk est un server‑side copy SMB 2.1 : le client demande au serveur de recopier des plages de données via l’IOCTL FSCTL_SRV_COPYCHUNK. C’est plus efficace qu’une copie « classique » client‑>réseau‑>serveur, mais moins performant qu’ODX car la baie ne fait pas un clonage « zéro‑copie » au niveau bloc.

Point crucial : on ne force pas ODX avec un bouton magique. Windows choisit dynamiquement ODX si et seulement si toutes les conditions suivantes sont vraies :

le serveur SMB (ONTAP) annonce et autorise le Copy Offload ;
source et destination résident sur un stockage capable de traiter un même token (même baie / même SVM, et selon la baie, parfois même agrégat/volume) ;
aucun minifiltre noyau (antivirus, DLP, chiffrement, HSM, synchronisation cloud…) n’impose une inspection qui interdit l’offload ;
le protocole négocié est SMB 3.x (Windows 10/11 utilisent en général 3.1.1).

Si une seule condition échoue, Windows bascule sur CopyChunk, voire sur une copie purement client côté réseau.

Vérifications côté Windows (PowerShell et outils natifs)

Confirmer la négociation SMB 3.x

Get-SmbConnection | Format-Table ServerName, ShareName, Dialect, NumOpens -AutoSize

Le champ Dialect doit afficher 3.0, 3.02 ou 3.1.1. Si vous voyez 2.x, ODX ne sera pas sélectionné.

Examiner la configuration ODX et les filtres

$fsKey = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
Get-ItemProperty -Path $fsKey -Name 'DisableODX','FilterSupportedFeaturesMode' | Format-List

# Inventaire des minifiltres actifs (suspects fréquents : antivirus, DLP, HSM, chiffrement)

fltmc filters
fltmc instances

DisableODX doit être absent ou égal à 0. Une valeur 1 désactive ODX globalement.
FilterSupportedFeaturesMode doit être 0 pour ne pas bloquer ODX/Trim/Block‑Clone. Toute valeur non nulle peut restreindre ces fonctions (bits cumulables).
Listez les filtres tiers (fltmc) ; désactivez temporairement ceux qui interceptent les I/O (AV, DLP, chiffrement, synchronisation) pour vos tests.

Vérifier l’état TRIM/UNMAP (indicateur connexe)

fsutil behavior query DisableDeleteNotify

Ce réglage concerne TRIM/UNMAP (pas ODX directement) ; s’il est désactivé par stratégie ou par un filtre, cela révèle souvent un environnement qui bride aussi ODX.

Observer ODX en temps réel (PerfMon et Get‑Counter)

Ajoutez dans Performance Monitor :

SMB Client Shares → Offloaded Read Bytes/sec, Offloaded Write Bytes/sec
SMB Server Shares → Offloaded Read Bytes/sec, Offloaded Write Bytes/sec (utile si vous testez côté serveur Windows ; pour ONTAP, utilisez ses compteurs internes).

Ou lancez un échantillonnage par script pendant une copie :

$ctr = '\SMB Client Shares\Offloaded Read Bytes/sec','\SMB Client Shares\Offloaded Write Bytes/sec'
1..10 | ForEach-Object {
  Get-Counter -Counter $ctr | Select-Object -ExpandProperty CounterSamples | 
    Select-Object Path, CookedValue
  Start-Sleep -Seconds 1
}

Des valeurs non nulles pendant votre copie indiquent qu’ODX est activement utilisé.

Capturer les IOCTL SMB pour distinguer ODX de CopyChunk

Avec Wireshark, filtrez smb2.ioctl et regardez la colonne Function :

FSCTL_OFFLOAD_READ et FSCTL_OFFLOAD_WRITE ⇒ ODX en cours.
FSCTL_SRV_COPYCHUNK ⇒ CopyChunk (server‑side copy SMB).

Attention : FSCTL_DUPLICATE_EXTENTS_TO_FILE correspond au clonage de blocs NTFS/ReFS local, pas à ODX sur SMB.

Fichiers de test et outils de copie

Testez avec un fichier nettement supérieur à quelques Mo (ex. 1–10 Go) pour éviter les heuristiques défavorables aux très petits fichiers.
Robocopy n’a aucun commutateur « /ODX » : ODX est transparent. Utilisez vos options habituelles (/MT, /R:0, /W:0, /Z si besoin).

# Exemple de copie de test
$src = '\\ontap-svm\share\bigfile.bin'
$dst = '\\ontap-svm\share\bigfile_copy.bin'
Measure-Command { Copy-Item -Path $src -Destination $dst }

Contrôles côté NetApp ONTAP 9.11.1 P13

Vérifier l’activation du Copy Offload

# ONTAP CLI (cluster or SVM scope)
vserver cifs options show -vserver &lt;SVM&gt; | grep -i 'Copy Offload'
# Au besoin :
vserver cifs options modify -vserver &lt;SVM&gt; -is-copy-offload-enabled true

Assurez‑vous que SMB2/SMB3 sont activés et que le SVM héberge bien vos partages concernés.

Valider la version SMB effectivement négociée

vserver cifs session show -vserver &lt;SVM&gt; -fields connection-id,client-ip,windows-version,protocol-version

Les sessions des postes Windows 10/11 doivent afficher une protocol‑version 3.x.

Comprendre les contraintes de topologie

Intra‑volume / intra‑SVM : c’est le cas le plus favorable. ODX a alors les meilleures chances de s’appliquer.
Cross‑volume / cross‑aggregate : selon la configuration et les licences (ex. FlexClone), ONTAP peut maintenir un offload côté baie. Sans ces capacités, le serveur SMB peut retomber sur CopyChunk.
Cross‑SVM ou cross‑cluster : souvent non éligible à ODX token‑based ; attendez‑vous à CopyChunk ou à une copie classique.

Compteurs ONTAP utiles

# Exemples indicatifs (varient selon versions)
statistics start -object cifs
# lancer la copie de test…
statistics show -object cifs -instance * -counter *offload*
statistics stop -object cifs

Checklist de dépannage orientée résultats

Élément	Action de contrôle	Résultat attendu
Version SMB	`Get-SmbConnection`	Dialect 3.x
ODX côté Windows	Registre `DisableODX`, `FilterSupportedFeaturesMode`	`DisableODX=0` ou absent, `FilterSupportedFeaturesMode=0`
Filtres de fichiers	`fltmc` (désactiver AV/DLP/HSM pour test)	ODX actif après neutralisation des filtres bloquants
Serveur ONTAP	`vserver cifs options show`	Copy Offload = Enabled
ODX observé	PerfMon (SMB Client/Server Shares)	Compteurs Offloaded * > 0 pendant la copie
Trame SMB	Wireshark `smb2.ioctl`	Présence de `FSCTL_OFFLOAD_*`, absence de `FSCTL_SRV_COPYCHUNK`
Taille fichier	Tester > 1 Mo (idéalement > 1 Go)	ODX plus susceptible d’être choisi
Réseau	Vérifier MTU, absence d’erreurs/fragmentation	Pas de timeouts qui forcent un fallback

Peut‑on « forcer » ODX ?

Non. ODX est une optimisation opportuniste. Il n’existe pas de commutateur ou de GPO pour obliger Windows à utiliser ODX. En revanche, vous pouvez rendre ODX le seul choix viable en supprimant les causes de repli :

Autoriser ODX côté ONTAP (Copy Offload = Enabled).
Lever les verrous côté client : DisableODX=0, FilterSupportedFeaturesMode=0, minifiltres tiers neutralisés.
Respecter la topologie : rester intra‑SVM/volume quand c’est possible ; activer les capacités de clonage/cross‑volume sur la baie si disponibles.
Valider SMB 3.x et la stabilité réseau.

Scripts et commandes prêts à l’emploi

Vérification rapide côté Windows

# 1) Négociation SMB
Get-SmbConnection | ft ServerName,ShareName,Dialect -AutoSize

# 2) Paramètres ODX

$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
(Get-ItemProperty -Path $path -Name DisableODX,FilterSupportedFeaturesMode -ErrorAction SilentlyContinue) |
Select-Object DisableODX,FilterSupportedFeaturesMode

# 3) Filtres potentiellement bloquants

fltmc filters

# 4) Compteurs ODX (client)

Get-Counter '\SMB Client Shares\Offloaded Read Bytes/sec','\SMB Client Shares\Offloaded Write Bytes/sec' -Continuous

Copie de test et journalisation minimale

$Src = '\\svm\share\test-bigfile.bin'
$Dst = '\\svm\share\test-bigfile-odx.bin'
$log = @()
$ctr = '\SMB Client Shares\Offloaded Read Bytes/sec','\SMB Client Shares\Offloaded Write Bytes/sec'

$job = Start-Job {
param($ctr)
while ($true) {
Get-Counter $ctr | Select -Expand CounterSamples |
Select Path,CookedValue, @{n='Time';e={Get-Date}}
Start-Sleep -Milliseconds 500
}
} -ArgumentList ($ctr)

try {
$dur = Measure-Command { Copy-Item $Src $Dst -Force }
} finally {
Stop-Job $job | Out-Null
Receive-Job $job -Keep | Tee-Object -Variable log | Out-Null
}

"Durée : $($dur.TotalSeconds) s"
$log | Where-Object { $_.CookedValue -gt 0 } | Select -First 5

Commandes ONTAP utiles

# ODX (Copy Offload)
vserver cifs options show -vserver <SVM> | grep -i 'Copy Offload'
# Activer si besoin
vserver cifs options modify -vserver <SVM> -is-copy-offload-enabled true

# Sessions SMB et versions négociées

vserver cifs session show -vserver  -fields client-ip,protocol-version,windows-version

# Partages concernés

vserver cifs share show -vserver  -share-name

Analyse fine avec Wireshark : filtres prêts à copier

Pour capturer l’échange pendant une unique copie :

Commencez un capture sur l’interface du poste Windows.
Démarrez la copie du fichier de test.
Appliquez le filtre d’affichage : smb2.ioctl.

Pendant la copie :

ODX : les paquets contiennent FSCTL_OFFLOAD_READ et FSCTL_OFFLOAD_WRITE.
CopyChunk : les paquets contiennent FSCTL_SRV_COPYCHUNK.

Si vous ne voyez aucun IOCTL ODX, revenez à la checklist : un filtre tiers ou une contrainte de topologie bloque l’offload.

Erreurs fréquentes et points d’attention

Confusion avec FSCTL_DUPLICATE_EXTENTS_TO_FILE : c’est le block‑clone NTFS/ReFS local, sans rapport direct avec ODX pour SMB.
Robocopy « /… » pour ODX : il n’existe pas d’option pour « forcer ODX ». ODX reste transparent si l’environnement s’y prête.
Fichiers très petits : Windows peut préférer une copie classique ; testez avec de gros fichiers pour trancher.
ODX et VM : pour des copies via SMB depuis une VM, l’hyperviseur n’a pas à « passer » UNMAP/WRITE SAME. En revanche, pour des copies in‑guest entre disques virtuels, les capacités ODX/VAAI du chemin de stockage de l’hyperviseur deviennent pertinentes.
Réseau instable : ODX n’a pas besoin de bande passante, mais des pertes/MTU incohérents peuvent provoquer des timeouts qui entraînent un repli sur CopyChunk.

Approche de résolution recommandée

Isoler : un poste Windows « propre » (pas d’AV/DLP/HSM), un gros fichier de test, une seule paire source→destination.
Contrôler le client : DisableODX=0, FilterSupportedFeaturesMode=0, Dialect SMB 3.x, filtres désactivés.
Contrôler ONTAP : Copy Offload = Enabled sur le SVM ; vérifier la session SMB 3.x.
Observer : PerfMon Offloaded * et Wireshark FSCTL_OFFLOAD_*.
Ajuster la topologie : rester intra‑SVM/volume ; activer le clonage/cross‑volume si votre licence le permet.
Rétablir progressivement les minifiltres jusqu’à identifier celui qui neutralise ODX.

FAQ éclair

ODX nécessite‑t‑il ReFS ? Non. NTFS suffit. ReFS/NTFS peuvent activer d’autres optimisations (block‑clone) mais ODX côté SMB ne l’exige pas.

ODX fonctionne‑t‑il entre deux partages sur des baies différentes ? En général non : les tokens ODX ne franchissent pas la frontière entre dispositifs de stockage hétérogènes. Attendez‑vous à CopyChunk ou à une copie réseau classique.

SMB Direct (RDMA) et Multichannel aident‑ils ODX ? Ce sont des accélérateurs réseau ; ODX clone côté baie et peut être sélectionné indépendamment. Toutefois, un réseau plus fiable diminue les risques de repli.

Modèles de diagnostics « copier‑coller »

Rapport de santé ODX côté Windows

$report = [ordered]@{
  Hostname = $env:COMPUTERNAME
  SmbDialect = (Get-SmbConnection | Select -First 1).Dialect
  DisableODX = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name DisableODX -ErrorAction SilentlyContinue).DisableODX
  FilterSupportedFeaturesMode = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name FilterSupportedFeaturesMode -ErrorAction SilentlyContinue).FilterSupportedFeaturesMode
  Filters = (fltmc filters | Select-String -NotMatch '------').ToString().Trim()
}
$report | Format-List

Filtre Wireshark prêt à l’emploi

smb2.ioctl and (smb2.ioctl.function == FSCTL_OFFLOAD_READ or smb2.ioctl.function == FSCTL_OFFLOAD_WRITE or smb2.ioctl.function == FSCTL_SRV_COPYCHUNK)

Notes complémentaires utiles

Des mises à jour Windows peuvent temporairement bloquer ODX si un minifiltre est instable. Vérifiez l’historique Windows Update et testez sans le pilote incriminé le cas échéant.
Pour contourner un stockage intermédiaire non compatible, l’activation d’un offload cross‑volume côté ONTAP (souvent associé à FlexClone) peut préserver le clonage côté baie.
En environnement virtualisé, ODX via SMB dépend surtout du serveur SMB et de la baie ; pour des I/O disque « in‑guest », assurez‑vous que le chemin de stockage de l’hyperviseur supporte les offloads nécessaires.

Résumé exécutif

Si la baie et les clients annoncent ODX mais qu’il n’est jamais sélectionné, la cause est presque toujours : (1) un minifiltre actif (AV/DLP/HSM), (2) une négociation SMB < 3.0, ou (3) un chemin de copie qui ne respecte pas les prérequis (topologie/volumes). La résolution passe par l’observation (PerfMon + Wireshark) et l’élimination méthodique de chaque point de blocage, jusqu’à voir apparaître FSCTL_OFFLOAD_* et des compteurs Offloaded * non nuls.

Annexe : commandes résumées

But	Commande
Dialecte SMB négocié	`Get-SmbConnection \| ft ServerName,ShareName,Dialect`
ODX activé côté Windows	`reg query HKLM\System\CurrentControlSet\Control\FileSystem /v DisableODX`
Filtres de fichiers	`fltmc filters`
Compteurs ODX (client)	`perfmon` → SMB Client Shares\Offloaded *
ODX activé côté SVM	`vserver cifs options show -vserver <SVM>`
Sessions SMB et version	`vserver cifs session show -vserver <SVM> -fields protocol-version`
Trames ODX vs CopyChunk	Wireshark `smb2.ioctl` → FSCTL_OFFLOAD_* / FSCTL_SRV_COPYCHUNK

Conclusion

ODX n’est pas un « mode » à enclencher manuellement mais une capacité qui se déclenche lorsque le client, le serveur SMB et la baie cochent toutes les cases. En procédant dans l’ordre — négociation SMB 3.x, activation ODX des deux côtés, neutralisation des minifiltres, validation topologique, puis observation PerfMon/Wireshark — vous obtiendrez un diagnostic fiable et la copie zéro‑copie qu’ODX promet réellement.

Astuce pratique : conservez deux profils PerfMon (avec et sans filtres tiers) et une capture Wireshark annotée. Ce « kit d’épreuve » vous servira de référence lors de toute régression future (nouvelle version d’un agent AV, migration de volume ou changement de topologie ONTAP).