¿Copias SMB lentas entre Windows y NetApp pese a tener ODX habilitado? En muchos entornos el cliente nunca pide ODX y todo cae en CopyChunk. Aquí tienes un diagnóstico paso a paso, qué mirar en capturas, cómo validar elegibilidad y la receta práctica para que el offload funcione de verdad.
Qué es ODX y por qué no “se fuerza”
ODX (Offloaded Data Transfer) delega la copia en la cabina usando tokens de datos. En lugar de leer y escribir por red, el servidor/almacenamiento realiza la transferencia internamente. Windows decide usar ODX de forma automática cuando todas estas piezas encajan:
- El cliente Windows soporta ODX y no está deshabilitado por directiva/registro.
- El servidor SMB anuncia y permite ODX (en ONTAP: “Copy Offload Enabled”).
- La operación y los archivos son elegibles (sin compresión NTFS/EFS/ADS, tamaño suficiente, etc.).
- Origen y destino residen en el mismo dominio de offload (misma cabina o ámbito donde el token sea válido).
No existe un método soportado para “forzar” ODX cuando alguna condición falla. En ese caso Windows usa SMB Server‑Side Copy (FSCTLSRVCOPYCHUNK) o la copia tradicional de lectura/escritura.
Cómo se ve ODX en la práctica
La confusión más común: dentro de un mismo servidor SMB (dos carpetas compartidas en la misma SVM/servidor), el cliente suele enviar FSCTLSRVCOPYCHUNK. Después, el servidor decide si internamente puede offloadear esa copia mediante ODX hacia el almacenamiento. Por eso, aunque no veas FSCTLOFFLOADREAD/WRITE en la traza del cliente, sí puede estar ocurriendo ODX por debajo en el servidor/ONTAP.
En cambio, entre dos servidores SMB distintos (cuando el token debe viajar de uno a otro), el cliente Windows intentará ODX en la propia sesión SMB y verás FSCTLOFFLOADREAD y FSCTLOFFLOADWRITE en la captura.
Herramientas para saber “qué comandos se usan”
| Necesidad | Herramienta | Qué buscar/esperar |
|---|---|---|
| Ver comandos SMB en la red | Wireshark (o netsh trace → Wireshark) | ODX: FSCTLOFFLOADREAD y FSCTLOFFLOADWRITE.Server‑Side Copy: FSCTLSRVCOPYCHUNK. |
| Validar offload sin captura | PerfMon | SMB Client Shares / Offloaded Read Bytes/sec, Offloaded Write Bytes/sec SMB Server / Offloaded Read Bytes/sec, Offloaded Write Bytes/sec Valores > 0 durante la copia confirman ODX. |
| Comprobación de filtros | PowerShell / FltMgr | fltmc instances para ver filtros que puedan impedir offload; con FilterSupportedFeaturesMode=0 y exclusiones adecuadas, ODX debería ser posible. |
| Estado de ODX en almacenamiento | ONTAP CLI | Verificar Copy Offload habilitado en la SVM y revisar estadísticas/registros durante la prueba. |
Captura rápida sin herramientas externas
# Inicia traza (incluye SMB) y genera etl
netsh trace start capture=yes persistent=no tracefile=C:\Temp\smb.etl
Realiza la copia de prueba (ej. entre dos shares)
...
Detén la traza
netsh trace stop
Abre smb.etl en Wireshark y busca:
- FSCTL\OFFLOAD\READ / FSCTL\OFFLOAD\WRITE (ODX)
- FSCTL\SRV\COPYCHUNK (server-side copy)
Checklist de elegibilidad: causas típicas por las que ODX no entra
| Factor | Impacto en ODX | Qué hacer |
|---|---|---|
| Archivo cifrado (EFS) o comprimido NTFS | Inhabilita ODX | Usa un archivo “limpio” (sin EFS/compresión). Prueba con > 1–2 GB. |
| Archivo disperso (sparse) o con streams alternativos (ADS) | Puede inhabilitar ODX | Evita sparse/ADS en la prueba; usa archivos regulares. |
| Copias a través de DFS Namespaces o diferentes FQDN | Puede cambiar el servidor de destino y romper el dominio del token | Para la prueba, monta y copia usando el mismo servidor SMB o dos servidores que compartan la misma cabina/ámbito ODX. |
| Filtros (AV/DLP/cifrado/EDR) en cliente o servidor | Pueden desactivar offload | Desactiva temporalmente o crea exclusiones para la ruta de prueba. |
| Registro/política deshabilitando ODX | ODX nunca se solicita | Comprueba DisableODX en cliente y servidor (0 o ausente). |
| Ámbito de token diferente (cabinas distintas) | ODX no funciona entre orígenes/destinos de cabinas no federadas | Asegura que ambos estén en la misma SVM/cabina o usa rutas compatibles. |
| SMB Dialect y capacidades | Si el servidor no anuncia lo necesario, no habrá ODX | Actualiza y verifica que el servidor SMB/ONTAP soporte ODX en ese share. |
Verificaciones en Windows
Cliente y servidor Windows
- Registro:
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\DisableODXdebe estar ausente o en 0. - Filtros:
FilterSupportedFeaturesMode=0(ya validado en tu caso). - Filtros activos:
fltmc instancespara revisar si hay controladores que bloqueen offload. - Actualizaciones: drivers de almacenamiento/NIC y parches al día (Windows 10/11 Pro y Server 2016–2022 soportan ODX).
Comprobación rápida de soporte del stack de disco
# Ver detalles de discos físicos (busca mención a offload en OperationalDetails)
Get-PhysicalDisk | Select MediaType, OperationalStatus, OperationalDetails | Format-List
Aunque esta consulta se centra en discos locales, es útil para detectar si el sistema no anuncia offload en absoluto. Para SMB, el factor decisivo será el servidor/almacenamiento.
Verificaciones en NetApp ONTAP
- Estado de Copy Offload en la SVM:
vserver cifs options show -vserver <SVM> Revisa "Copy Offload Enabled: true" - Habilitar Copy Offload si fuera necesario:
vserver cifs options modify -vserver <SVM> -copy-offload-enabled true - Ámbito: verifica que origen y destino residan en el mismo ámbito ODX (misma cabina/SVM o entorno donde el token sea válido). Entre cabinas distintas es habitual que el token no aplique.
- Observabilidad: consulta estadísticas/logs de la SVM durante la prueba para confirmar operaciones de copy offload (nombres de contadores pueden variar por versión).
Contexto de versión: tu entorno indica ONTAP 9.11.1P13. ODX/Copy Offload está soportado en ONTAP desde versiones muy anteriores; asegúrate de que la SVM que publica los shares es la que tiene la opción activa.
Prueba controlada recomendada
- Prepara un archivo “limpio”: 2–10 GB, creado con
fsutil file createnewo un VHDX de prueba sin compresión/EFS/ADS. - Elige rutas:
- Escenario A (mismo servidor SMB): copia entre dos shares publicados por la misma SVM/servidor. En la red verás
FSCTLSRVCOPYCHUNK; si el back‑end es apto, el servidor offloadeará internamente mediante ODX. - Escenario B (dos servidores SMB): copia entre shares de dos servidores distintos que apunten a la misma cabina/ámbito ODX. Aquí deberías ver
FSCTLOFFLOADREAD/WRITEen la captura si todo es elegible.
- Escenario A (mismo servidor SMB): copia entre dos shares publicados por la misma SVM/servidor. En la red verás
- Lanza la copia con
robocopyevitando tocar atributos (cambios de atributos pueden inhibir ODX):# Ejemplo: copia 1 archivo, no copia atributos que no sean necesarios robocopy \\srv\src \\srv\dst archivo.prueba /COPY:DAT /R:1 /W:1 /NFL /NDL /NP - Monitorea PerfMon:
- En el cliente: SMB Client Shares / Offloaded Read/Write Bytes/sec.
- En el servidor: SMB Server / Offloaded Read/Write Bytes/sec.
- Traza de confirmación con
netsh trace+ Wireshark y busca los FSCTL indicados.
Cómo interpretar lo que ves en la captura
- Ves FSCTLSRVCOPYCHUNK y no aparece ningún OFFLOAD: en un mismo servidor SMB es lo esperado; el offload puede estar ocurriendo en el back‑end sin exponerse como ODX en la sesión SMB. Corrobóralo con PerfMon en el servidor y con métricas de ONTAP.
- Entre dos servidores SMB ves
FSCTLOFFLOADREADseguido deFSCTLOFFLOADWRITE: ODX activo extremo a extremo. - No ves OFFLOAD ni COPYCHUNK y solo lectura/escritura: no hay server‑side copy ni ODX; probablemente alguna condición de elegibilidad está fallando.
Factores de ruta que suelen romper ODX
- DFS (referrals): al resolver a un destino diferente, el token puede no ser válido o el cliente decide CopyChunk/lectura tradicional.
- Rutas distintas hacia la misma share (ej. FQDN vs alias vs IP): Windows trata cada UNC como un servidor diferente; mantén consistencia.
- SMB multicanal/transparente a fallos: no suelen impedir ODX, pero si cambias de NIC/endpoint a mitad de la copia, la sesión podría renegociar.
- Cuotas, clasificación, FSRM o filtros DLP: algunos drivers bloquean offload; crea exclusiones para la prueba.
Validaciones y comandos útiles
Windows: estado de ODX y filtros
# 1) ODX habilitado (0 o ausente)
reg query HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v DisableODX
2) Filtros del Filter Manager (revisa DLP/AV/Encryption)
fltmc instances
3) Dialect SMB y conexión (diagnóstico general)
Get-SmbConnection | Select ServerName,ShareName,Dialect,NumOpens Windows: contadores PerfMon clave
- SMB Client Shares: Offloaded Read Bytes/sec, Offloaded Write Bytes/sec.
- SMB Server: Offloaded Read Bytes/sec, Offloaded Write Bytes/sec.
ONTAP: opciones CIFS/SMB
# Ver opciones y estado en la SVM
vserver cifs options show -vserver <SVM>
Habilitar Copy Offload (si estuviera desactivado)
vserver cifs options modify -vserver \ -copy-offload-enabled true Plan de acción recomendado
- Validar configuración:
- Windows:
DisableODX=0o ausente;FilterSupportedFeaturesMode=0. - ONTAP: Copy Offload Enabled: true en la SVM que publica las shares.
- Filtros AV/DLP con exclusiones temporales en la ruta de prueba.
- Windows:
- Realizar una prueba controlada con un archivo grande y “limpio” entre dos shares del mismo servidor SMB (para observar
FSCTLSRVCOPYCHUNKen la red) y medir ODX por PerfMon en el servidor. - Repetir la prueba entre dos servidores SMB que compartan cabina/ámbito ODX para observar
FSCTLOFFLOADREAD/WRITEen la captura. - Si no entra ODX:
- Elimina factores bloqueantes (DFS, compresión/EFS, sparse, streams alternativos, atributos extra).
- Usa la misma SVM/cabina para origen y destino.
- Confirma que no hay políticas o drivers que deshabiliten offload.
- Recoger evidencias: capturas con los FSCTL, contadores de PerfMon > 0, y registros/estadísticas de ONTAP.
- Escalar a soporte NetApp/Microsoft con las evidencias si el comportamiento persiste tras eliminar los bloqueantes.
Preguntas frecuentes
¿Puedo “forzar” ODX?
No. Solo puedes habilitar ODX y garantizar elegibilidad. Si las condiciones no encajan, Windows elige CopyChunk o lectura/escritura.
¿Por qué mis clientes nunca envían FSCTLOFFLOAD*?
Porque estás copiando dentro del mismo servidor SMB. En ese caso el cliente usa FSCTLSRVCOPYCHUNK y el propio servidor decide offloadear al almacenamiento mediante ODX. Compruébalo mirando los contadores de SMB Server Offloaded* en PerfMon o métricas de ONTAP.
¿Qué tamaño mínimo activa ODX?
No hay un “número mágico” documentado universal, pero en la práctica archivos muy pequeños se copian por lectura/escritura tradicional o CopyChunk; usa varios GB para las pruebas.
¿SMB Encryption o Signing impiden ODX?
No deberían, porque la decisión de offload es del servidor sobre datos que ya ve en claro. Aun así, si cambias de sesión o endpoint durante la copia (por ejemplo, reconexión de multicanal), podrías ver renegociaciones y caídas de offload.
Guía de diagnóstico express
- Comprueba registro en cliente y servidor:
DisableODXen 0/ausente. - Verifica ONTAP: Copy Offload Enabled en la SVM.
- Prueba con archivo grande y
robocopy /COPY:DATsin adornos. - PerfMon: mira Offloaded Read/Write Bytes/sec en cliente y servidor.
- Captura: busca
FSCTLOFFLOAD*(entre servidores) oFSCTLSRVCOPYCHUNK(mismo servidor). - Ajusta: evita DFS, filtros, compresión/EFS; usa mismo FQDN/servidor/SVM.
Resumen operativo
ODX no se “activa” por decreto: Windows lo usa cuando cliente, servidor y almacenamiento están alineados y el archivo/operación es elegible. Si trabajas dentro del mismo servidor SMB, verás FSCTLSRVCOPYCHUNK en la red; el offload real ocurre entre el servidor y la cabina. Para tener la prueba inequívoca:
- PerfMon con Offloaded Read/Write Bytes/sec > 0 (cliente/servidor).
- Captura SMB con
FSCTLOFFLOADREAD/WRITEen escenarios entre servidores.
Con esa metodología podrás distinguir si el problema es de visibilidad (esperas ver ODX en el cable cuando en realidad pasa dentro del servidor) o de elegibilidad (algún factor bloquea el offload).
Conclusión: si tu entorno Windows 10/11 y Windows Server 2016–2022 con NetApp ONTAP 9.11.1P13 no “activa” ODX, sigue el plan: valida DisableODX y Copy Offload en la SVM, elimina bloqueantes (DFS, filtros, compresión/EFS), ejecuta una prueba controlada con archivo grande y confirma con PerfMon/tra zas. Asume que en copias intra‑servidor verás CopyChunk en la red y el offload en el back‑end. Solo cuando todo sea elegible y, si aplica, entre servidores, verás los FSCTLOFFLOAD* en la sesión SMB.