Manejadores duraderos SMB en ZFS: por qué copiar/mover se siente raro

El modelo mental: qué significa realmente “duradero”

Empieza con una afirmación directa: SMB no es “solo E/S de archivos”. Es un protocolo con estado que mantiene en el servidor memoria de lo que hace un cliente.
Los manejadores duraderos forman parte de esa memoria.

En SMB2/SMB3, un cliente abre un archivo y recibe un manejador. Ese manejador representa un estado vivo: bloqueos, modos de compartición, bloqueos por rango de bytes,
derechos de caché y a veces un lease (una promesa estructurada sobre caché y coherencia). Si la red titubea, tradicionalmente el cliente perdería el manejador.
Las aplicaciones entonces obtienen “archivo no encontrado” o “nombre de red ya no disponible” y todos culpan al almacenamiento.

Los manejadores duraderos solucionan eso: el servidor puede mantener el estado de apertura por un tiempo para que el cliente se reconecte y “reclame” la apertura.
La reconexión puede incluso ocurrir tras un reset TCP, un fallo de Wi‑Fi o la suspensión de un portátil. Es una característica de fiabilidad. El coste es que
el servidor debe preservar y validar más estado, y debe ser cuidadoso cuando los archivos se renombran/mueven mientras existen aperturas.

Ahora añade ZFS. ZFS es muy bueno preservando consistencia en disco y proporcionando identidad de objeto estable. SMB es muy bueno preservando
la consistencia de archivos abiertos a través de reconexiones. Juntos consiguen corrección. También obtienes picos de latencia visibles en lugares
que los usuarios de Windows interpretan como “¿por qué mover actúa como copiar?”

Por qué copiar/mover se siente raro en SMB sobre ZFS

1) “Mover” es solo un renombrado si el servidor puede hacer un renombrado atómico

En un volumen NTFS local, mover dentro del mismo sistema de archivos suele ser un renombrado de metadatos: rápido, atómico y sin tocar los datos del archivo.
En SMB, Explorer pide al servidor que haga un renombrado (SMB2 SET_INFO / FileRenameInformation). Si el renombrado está dentro del mismo recurso compartido y el
servidor puede mapearlo a un renombrado simple, puede ser rápido.

Pero si el “mover” cruza límites que el servidor considera no atómicos—diferentes recursos compartidos, diferentes sistemas de archivos subyacentes, diferentes
datasets montados por separado, o una ruta que toca una política de un módulo VFS distinto—el servidor puede responder “no puedo hacer eso como renombrado”.
Entonces el cliente recurre a copiar+borrar. Esa es la primera fuente de “raro”.

2) Los manejadores duraderos hacen que el servidor sea cauteloso con renombrados y borrados

Si un archivo está abierto con un manejador duradero y el cliente podría reconectarse para seguir escribiendo, el servidor debe preservar las semánticas:
el manejador debería seguir refiriéndose al mismo objeto archivo tras un renombrado. Eso es factible si el servidor sigue IDs de archivo de forma fiable.
Pero cambia el perfil de coste. Operaciones que antes eran “solo renombrar una entrada” ahora implican:

• Actualizar tablas de manejadores duraderos y estado de ruptura de leases
• Validar que los modos de compartición se respetan para el nuevo nombre/ubicación
• Asegurar que el renombrado sea visible y coherente para otros clientes
• Potencialmente romper leases/oplocks para que otros clientes invaliden cachés

Ese trabajo no es gratis. Si el servidor está ocupado, o la E/S de metadatos es lenta, un renombrado puede tardar lo suficiente como para que Explorer parezca
que está “copiando”. La interfaz no es una máquina de la verdad; es sensación más barra de progreso.

3) “Mover instantáneo” seguido de archivos persistentes suele ser borrado demorado o retención de manejadores

Otro caso raro: mueves una carpeta, aparece en el destino, pero también sigue visible en el origen durante un tiempo. Hay varias razones honestas:

• Cacheo de entradas de directorio en el cliente (Explorer es agresivamente optimista).
• Manejadores abiertos que impiden la eliminación; el servidor marca para delete-on-close.
• Snapshots o retenciones que hacen que los datos persistan incluso si el espacio de nombres en vivo cambió (el espacio de nombres cambia; los bloques permanecen).
• Movimientos entre datasets que se implementan como copy+delete; la eliminación espera a que se cierren las aperturas.

4) Los límites de dataset de ZFS convierten renombrados en copias, aunque las rutas parezcan “cercanas”

Los datasets de ZFS no son directorios con un nombre bonito. Son sistemas de archivos separados con sus propios puntos de montaje, propiedades y a veces distinto
recordsize, compresión, esquema de xattr y comportamiento de ACL. Un renombrado entre datasets no es atómico. El servidor SMB no puede hacer un
renombrado de un único sistema de archivos cuando origen y destino no son el mismo.

Eso significa que el “mover” de Explorer se convierte en “copiar y luego borrar”. Los usuarios no saben (ni les importa) qué es un dataset. Solo ven una operación
que antes era instantánea y ahora dura minutos. Puedes educarlos, o diseñar los recursos compartidos para hacer invisibles los límites de dataset en sus flujos de trabajo. Elige uno. Solo uno ocurrirá.

5) El metadato SMB es verboso; el metadato de ZFS puede ser costoso bajo carga

Copiar un árbol de directorios no es solo datos. Es un festival de metadatos: crear, establecer seguridad, establecer tiempos, establecer atributos, streams alternativos,
consultar info, abrir/cerrar. Los manejadores duraderos y leases añaden transiciones de estado a ese festival. ZFS bajo carga sincrónica intensa o con IOPS de metadatos
limitadas hará que ese festival parezca un desfile lento.

Chiste corto #1: Los manejadores duraderos son como conservar tu ticket de parking después de salir del garaje—útil, a menos que el empleado también espere que dejes el coche ahí para siempre.

Hechos interesantes y un poco de historia

1. SMB2 llegó con Windows Vista/Server 2008 y redujo drásticamente la “verbosidad de SMB1” al agrupar y canalizar operaciones.
2. Los manejadores duraderos aparecieron en SMB2.1 (era Windows 7/Server 2008 R2) para sobrevivir a desconexiones transitorias sin reintentos a nivel de aplicación.
3. SMB3 añadió “manejadores persistentes” principalmente para recursos continuamente disponibles en servidores en clúster; son más fuertes que los “duraderos”.
4. Los opportunistic locks (oplocks) existían mucho antes de SMB2; SMB2+ los generalizó en leases con semánticas más claras.
5. La interfaz de progreso de Windows Explorer no es un analizador de protocolo; frecuentemente etiqueta mal copiar vs mover cuando ocurren retrocesos.
6. El renombrado en ZFS es atómico dentro de un dataset, pero no entre datasets; se convierte en una operación de mayor nivel copy+unlink.
7. Las snapshots de ZFS no “congelan” el sistema de archivos en vivo; preservan bloques antiguos. Los borrados después de una snapshot pueden convertirse en trabajo de recuperación de espacio más tarde.
8. Samba implementa manejadores duraderos en espacio de usuario; el rendimiento y las semánticas dependen del comportamiento del VFS del kernel, soporte de xattr y los módulos vfs elegidos.
9. SMB usa IDs de archivo para identificar archivos más allá de los nombres. Los servidores que pueden proporcionar IDs estables tipo inode hacen que las semánticas duraderas sean más manejables.

Manejadores duraderos vs leases/oplocks vs manejadores “persistentes”

Manejadores duraderos

Un manejador duradero trata sobre la reconexión. El servidor mantiene el estado después de una desconexión para que el cliente pueda reclamarlo.
El servidor decide cuánto tiempo lo conserva y en qué condiciones es válido. Los manejadores duraderos son comunes en pilas SMB modernas.

Leases (y oplocks)

Los leases tratan sobre la caché. Permiten al cliente cachear lecturas, escrituras y metadatos con menos rondas. Cuando otro cliente quiere acceso conflictivo,
el servidor “rompe” el lease y el cliente vacía/invalidar cachés. Las rupturas de lease pueden parecer pausas aleatorias durante copiar/mover porque el servidor está forzando coherencia.

Manejadores persistentes

Los manejadores persistentes son la variante “no pierdas mi manejador aunque el servidor falle” pensada para recursos continuamente disponibles en almacenamiento en clúster.
Si no ejecutas un clúster diseñado para esto, esperar manejadores persistentes puede hacerte daño.

La lección práctica: los manejadores duraderos mantienen las cosas correctas durante la reconexión; los leases hacen que las cosas sean rápidas hasta que deben ser correctas.
El comportamiento extraño de copiar/mover suele ser la transición entre esos dos modos.

Idea parafraseada — Richard Cook: “Los sistemas complejos fallan de formas complejas; los operadores deben reconciliar continuamente cómo se hace realmente el trabajo.”

Mecánica de ZFS que importa: IDs, txgs, xattrs, snapshots

Identidad de archivo estable: comportamiento tipo inode e IDs de archivo SMB

Los clientes SMB se benefician cuando el servidor puede proporcionar IDs de archivo estables para que “mismo objeto, nuevo nombre” siga siendo verdadero tras un renombrado.
ZFS tiene fuerte identidad interna de objetos. Samba (o tu pila SMB) mapea eso a IDs de archivo SMB. Si ese mapeo es estable, la reclamación de manejadores duraderos
tras un renombrado es más segura. Si no lo es, el servidor se vuelve conservador: más comprobaciones, más rupturas, más retrocesos.

Transaction groups (txgs) y comportamiento sync

ZFS agrupa cambios en transaction groups. Muchos pequeños updates de metadatos durante una copia de directorio pueden acumularse y luego vaciarse.
Si tu carga de trabajo dispara semánticas síncronas (sync explícito, o configuraciones SMB que lo implican por durabilidad), puedes obtener paradas periódicas cuando el sistema espera actividad del intent log y commits de txg.

Esta es una razón por la que ocurre “copiar es suave, mover es con picos”: las operaciones de mover pueden generar ráfagas de updates de metadatos y secuencias rename/unlink
que golpean puntos sync de manera diferente a las escrituras secuenciales.

xattrs y streams de datos alternativos

Windows usa alternate data streams (ADS). Los servidores SMB suelen implementar ADS usando atributos extendidos. En ZFS, los xattrs pueden almacenarse de distintas formas
(dependiendo de la implementación), y los metadatos de archivos pequeños pueden convertirse en mucha E/S aleatoria si tienes presión de memoria.
Copiar desde Windows a menudo incluye descriptores de seguridad, identificadores de zona y otros metadatos que “deberían ser baratos”, hasta que no lo son.

Snapshots: el movimiento ocurrió, pero el espacio no volvió

Los usuarios dicen “lo moví, ¿por qué el pool sigue lleno?” Snapshots. Un movimiento dentro del mismo dataset puede solo renombrar entradas; el espacio no cambia.
Un copy+delete entre datasets puede liberar espacio en el dataset origen, pero si el origen tiene snapshots, los bloques siguen referenciados.
Desde la perspectiva de capacidad, “borrar” se convierte en “marcar libre en el árbol en vivo pero aún referenciado por snapshot”. Eso es correcto. También confunde si miras el espacio libre como si fuera un ticker bursátil.

Modos de fallo que parecen “SMB está lento” pero no lo son

Tormentas de renombrado que disparan rupturas de lease

Los grandes movimientos de árboles de directorios son tormentas de renombrado. Si otros clientes están navegando esos directorios, el servidor debe mantener vistas coherentes.
Las rupturas de lease se propagan. Tu “movimiento simple” se convierte en un ejercicio de coordinación entre múltiples clientes.

Antivirus e indexación de contenido convierten metadatos en latencia

En Windows, Defender (o el antivirus corporativo) ama los archivos nuevos. Copiar crea archivos nuevos. Mover-como-copiar crea archivos nuevos. El cliente los leerá,
los hasheará y a veces los reabrirá. Eso aumenta aperturas y cierres SMB, que interaccionan con las tablas de manejadores duraderos y modos de compartición.
El almacenamiento recibe la culpa por el entusiasmo del equipo de seguridad.

Presión del ARC y amplificación de pequeñas E/S en ZFS

Copiar muchos archivos pequeños es una carga de metadatos y pequeñas E/S. Si ARC está presionado, el sistema comienza a hacer lecturas reales en disco para metadatos
que de otro modo estarían en caché. La latencia sube. La latencia SMB sube. Explorer declara el movimiento “calculando…” para siempre.

Movimientos entre recursos compartidos: impuesto UX por límites administrativos limpios

A los admins les encantan los múltiples recursos compartidos. A los usuarios les encanta “se mueve instantáneamente”. Esas cosas suelen ser mutuamente excluyentes.
Un movimiento entre recursos compartidos suele no poder ser un renombrado del servidor. El cliente copia y borra, que es correcto pero no rápido.

Tareas prácticas: comandos, salidas y decisiones

Estos son los chequeos que hago cuando alguien dice “los movimientos SMB son raros en ZFS”. Cada tarea tiene: el comando, qué significa la salida y la
decisión que tomas basándote en ello.

Tarea 1: Confirmar límites de dataset y puntos de montaje

cr0x@server:~$ zfs list -o name,mountpoint -r tank/smb
NAME               MOUNTPOINT
tank/smb           /tank/smb
tank/smb/users     /tank/smb/users
tank/smb/projects  /tank/smb/projects
tank/smb/archive   /tank/archive

Significado: tank/smb/archive está montado en otro sitio. Un “mover” desde /tank/smb/projects a /tank/smb/archive cruza sistemas de archivos.

Decisión: Si los usuarios mueven rutinariamente entre esas rutas, o bien unificas en un solo dataset o aceptas el comportamiento copy+delete (y se lo comunicas).

Tarea 2: Verificar que origen y destino sean el mismo sistema de archivos desde la vista del kernel

cr0x@server:~$ stat -f -c '%T %m' /tank/smb/projects /tank/archive
zfs /tank/smb/projects
zfs /tank/archive

Significado: Ambos son ZFS, pero eso no significa mismo dataset. stat -f no diferenciará datasets ZFS; solo dice “zfs”.

Decisión: Usa la Tarea 1 más un mapa de shares. No supongas que “mismo pool” significa “mismo sistema de archivos”.

Tarea 3: Mapear shares SMB a rutas de sistema de archivos (Samba)

cr0x@server:~$ testparm -s 2>/dev/null | sed -n '/^\[users\]/,/^\[/{/path =/p}'
	path = /tank/smb/users

Significado: El recurso [users] apunta a /tank/smb/users. Haz esto para ambos shares implicados en el “mover”.

Decisión: Si el movimiento cruza shares, espera copy+delete por parte del cliente a menos que uses funciones de copia del servidor y el cliente las soporte bien.

Tarea 4: Observar sesiones SMB y archivos abiertos en vivo

cr0x@server:~$ smbstatus --shares --processes
Service      pid     Machine       Connected at                     Encryption   Signing
users        21408   10.20.30.44    Tue Dec 26 09:10:12 2025 UTC     -            -
projects     22119   10.20.30.44    Tue Dec 26 09:11:05 2025 UTC     -            -

Significado: El mismo cliente está conectado a varios shares. Un movimiento entre shares probablemente será copy+delete.

Decisión: Si esto es un flujo frecuente, considera presentar una raíz de share única que mantenga los movimientos comunes dentro de un share y dataset.

Tarea 5: Identificar comportamiento de manejadores duraderos y leases en logs de Samba

cr0x@server:~$ grep -E 'durable|lease|oplock' /var/log/samba/log.smbd | tail -n 8
[2025/12/26 09:17:41.231112,  3] smbd/smb2_oplock.c:3177(smbd_smb2_request_process_break)
  Sending break for lease key 9c3c2b0d...
[2025/12/26 09:17:41.245891,  3] smbd/smb2_server.c:4041(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: idx[1] status[STATUS_OPLOCK_BREAK_IN_PROGRESS]

Significado: Están ocurriendo rupturas de lease. Eso es el servidor forzando que los clientes vacíen cachés, a menudo durante tormentas de renombrado.

Decisión: Si las rupturas de lease correlacionan con el “mover raro”, reduce la exploración concurrente de directorios durante migraciones o programa los movimientos fuera de horario.

Tarea 6: Comprobar propiedades del dataset ZFS que afectan el comportamiento de metadatos SMB

cr0x@server:~$ zfs get -H -o name,property,value atime,xattr,acltype,casesensitivity,recordsize,sync tank/smb/projects
tank/smb/projects	atime	off
tank/smb/projects	xattr	sa
tank/smb/projects	acltype	posixacl
tank/smb/projects	casesensitivity	mixed
tank/smb/projects	recordsize	1M
tank/smb/projects	sync	standard

Significado: xattr=sa puede ser bueno para cargas con muchos metadatos; recordsize=1M está bien para archivos grandes pero no decide en tormentas de archivos pequeños.

Decisión: Si ves mucho tráfico ADS/xattr y E/S aleatoria, valida la estrategia de xattr y considera un dataset afinado para archivos pequeños (y mantén los movimientos dentro de él).

Tarea 7: Comprobar presión de snapshots cuando “borrar no liberó espacio”

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,mountpoint -r tank/smb/projects | head
NAME                                USED  REFER  MOUNTPOINT
tank/smb/projects@daily-2025-12-25   118G  2.4T   -
tank/smb/projects@daily-2025-12-26   6.1G  2.5T   -

Significado: Las snapshots referencian mucho. Borrar/mover archivos no liberará esos bloques hasta que se eliminen las snapshots.

Decisión: Si la capacidad es el problema, ajusta la retención de snapshots o mueve datos a un dataset sin snapshots de larga duración (pero hazlo con conocimiento).

Tarea 8: Observar txg y latencia de E/S durante la operación

cr0x@server:~$ iostat -x 2 5
Linux 6.6.44 (server) 	12/26/2025 	_x86_64_	(32 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          12.1  0.0     6.8     9.7     0.0    71.4

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         215.0   480.0  8200.0 51200.0   8.40   0.35   24.0
sdg             120.0   900.0  1400.0 18000.0  38.20   1.10   95.0

Significado: Un dispositivo está al máximo de %util y con alto await. Ahí es donde tu “renombrado” está esperando.

Decisión: Si los metadatos aterrizan en vdevs lentos, arregla el layout de vdevs, añade clases de asignación especiales (donde aplique) o reduce operaciones pesadas en metadatos durante pico.

Tarea 9: Comprobar eficiencia y presión del ARC (Linux)

cr0x@server:~$ arcstat 2 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
09:20:11  12K  3.1K     25   510   16   2.6K   84     0    0   92G   110G
09:20:13  15K  5.9K     39   820   14   5.1K   86     0    0   92G   110G
09:20:15  14K  6.2K     44   900   14   5.3K   86     0    0   92G   110G

Significado: La tasa de fallos es alta y mayormente fallos de prefetch. Estás haciendo trabajo aleatorio de metadatos/archivos pequeños que no se mantiene caliente.

Decisión: Si esto correlaciona con tormentas de copiar/mover, añade RAM, reduce concurrencia o mueve metadatos a medios más rápidos si tu plataforma lo soporta.

Tarea 10: Confirmar si la operación es renombrado o copy+delete desde el lado cliente (Windows vía logs del servidor)

cr0x@server:~$ grep -E 'rename|unlink|NT_STATUS|SET_INFO' /var/log/samba/log.smbd | tail -n 10
[2025/12/26 09:21:44.101220, 10] smbd/smb2_trans2.c:3920(smbd_smb2_setinfo_file)
  SMB2_SETINFO_FILE: FileRenameInformation
[2025/12/26 09:21:44.141109, 10] smbd/close.c:871(close_normal_file)
  closed file users/alice/report.xlsx (numopen=0) NT_STATUS_OK

Significado: Estás viendo FileRenameInformation, así que al menos parte del movimiento es un renombrado real.

Decisión: Si la interfaz muestra “copiando” pero los logs muestran renombrado, céntrate en latencia de metadatos/rupturas de lease—no en el rendimiento de datos.

Tarea 11: Comprobar opciones a nivel de share que cambian comportamiento sync/durabilidad

cr0x@server:~$ testparm -s 2>/dev/null | grep -E 'strict sync|sync always|durable handles|kernel oplocks|oplocks|leases'
	kernel oplocks = no
	oplocks = yes
	leases = yes
	strict sync = yes

Significado: strict sync = yes puede forzar semánticas síncronas para ciertas operaciones, aumentando latencia bajo tormentas de metadatos.

Decisión: No desactives strict sync a ciegas. En su lugar, decide por share según la criticidad de datos. Para directorios personales quizá; para contabilidad, probablemente no.

Tarea 12: Detectar “mover se convirtió en copia” vía volumen de escritura inesperado

cr0x@server:~$ zpool iostat -v tank 2 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        88.2T  21.5T    220   1600   18M   220M
  raidz2-0  40.1T  10.2T    110    900   10M    120M
    sdg         -      -     30    260  2.5M    34M
    sdh         -      -     25    230  2.1M    30M
  raidz2-1  48.1T  11.3T    110    700  8.0M   100M
    sdi         -      -     28    210  2.0M    29M
    sdj         -      -     26    190  1.8M    27M

Significado: Un “mover” dentro de un dataset no debería generar cientos de MB/s de escrituras sostenidas. Si lo hace, es una copia.

Decisión: Replantea límites de share/dataset. Si los usuarios deben mover entre datasets, planifica el throughput y la sobrecarga de antivirus; no prometas velocidad de renombrado.

Tarea 13: Comprobar presión de enumeración de directorios (¿estamos haciendo millones de LOOKUPs?)

cr0x@server:~$ nfsstat -c 2>/dev/null || true
nfsstat: NFS not running

Significado: No es NFS—bien. Para presión de enumeración SMB confiarás en logs de SMB, contadores de perf y trazado de llamadas al sistema.

Decisión: Si no puedes instrumentar SMB correctamente, sube el nivel de log de Samba brevemente en una sola IP cliente y captura el comportamiento rename/copy directamente.

Tarea 14: Trazar syscalls rename/unlink durante un “mover” (servidor Linux)

cr0x@server:~$ sudo strace -f -p $(pidof smbd | awk '{print $1}') -e trace=rename,renameat,unlink,unlinkat -s 128 -tt -o /tmp/smbd.rename.trace & sleep 5; tail -n 5 /tmp/smbd.rename.trace
09:23:10.118023 renameat(AT_FDCWD, "/tank/smb/projects/Q4/budget.xlsx", AT_FDCWD, "/tank/smb/projects/Q4-archive/budget.xlsx") = 0
09:23:10.118771 unlinkat(AT_FDCWD, "/tank/smb/projects/Q4/tmp~budget.xlsx", 0) = 0

Significado: Estás viendo llamadas reales renameat. Eso sugiere que el renombrado del lado servidor está ocurriendo—la lentitud probablemente sean bloqueos/rupturas de lease o E/S de metadatos.

Decisión: Si ves volumen de open/read/write en lugar de renombres, es copy+delete. Arregla primero el problema de límites.

Tarea 15: Detectar borrados bloqueados por manejadores abiertos (Samba)

cr0x@server:~$ smbstatus --locks | head -n 12
Locked files:
Pid    Uid   DenyMode   Access      R/W        Oplock           SharePath   Name   Time
22119  1050  DENY_NONE  0x120089    RDONLY     EXCLUSIVE+BATCH  /tank/smb/projects  Q4/budget.xlsx  Tue Dec 26 09:23:44 2025

Significado: Un cliente tiene un oplock/lease (mostrado como oplock aquí). El borrado o movimiento puede necesitar una ruptura; si el cliente responde lentamente, esperas.

Decisión: Si un cliente está reteniendo bloqueos y bloqueando operaciones, atiende ese cliente (portátiles en suspensión, apps abiertas) antes de tocar el almacenamiento.

Guion de diagnóstico rápido

Cuando un “mover” se siente como un “copiar”, no empieces cambiando tunables de ZFS. Empieza por averiguar qué operación está ocurriendo realmente.
Aquí el orden que ahorra tiempo.

Primero: ¿es renombrado o copy+delete?

• Comprueba rutas de shares y límites de dataset (Tarea 1, Tarea 3).
• Observa si hay ancho de banda de escritura sostenido durante un “mover” (Tarea 12).
• Busca llamadas de renombrado SMB en logs o traza syscalls (Tarea 10, Tarea 14).

Si es copy+delete: deja de culpar a los manejadores duraderos. Tu arquitectura forzó la caída al fallback.

Segundo: si es renombrado, ¿por qué espera?

• Busca rupturas de lease/oplock y STATUS_OPLOCK_BREAK_IN_PROGRESS (Tarea 5).
• Comprueba borrados bloqueados o manejadores abiertos (Tarea 15).
• Correlaciona con latencia de disco/IO wait (Tarea 8).

Si son rupturas de lease: reduce la concurrencia, evita renombrados masivos en hora punta y considera cambios en el layout de shares.

Tercero: ¿es la E/S de metadatos el cuello de botella?

• Revisa tasas de fallo del ARC (Tarea 9).
• Valida propiedades del dataset para la carga (Tarea 6).
• Verifica que las snapshots no oculten expectativas de “delete” (Tarea 7).

Si son metadatos: la solución es metadatos más rápidos, más memoria, menos tormentas de archivos pequeños o mejor programación—rara vez “apagar manejadores duraderos”.

Tres micro-historias del mundo corporativo

Incidente: la suposición equivocada (“un mover siempre es un renombrado”)

Una empresa mediana tenía una taxonomía de almacenamiento limpia: un dataset ZFS por departamento, un recurso SMB por dataset, cuotas ordenadas, snapshots ordenadas.
El servidor de archivos era sano y aburrido—hasta el cierre trimestral de finanzas. De repente, “mover” carpetas al share de archivo tardaba horas.
Llegaron tickets de helpdesk y alguien declaró que el pool ZFS estaba “degradado” porque Windows decía “Preparando para mover…”.

La suposición equivocada fue simple: asumieron que un mover dentro del “mismo servidor” es un renombrado. Pero el archivo estaba en un share diferente
y en un dataset diferente. Windows hizo copy+delete. El antivirus escaneó los archivos nuevos. Las herramientas de hoja de cálculo de finanzas los volvieron a abrir.
El servidor SMB hizo exactamente lo que debía: aplicar modos de compartición y mantener aperturas duraderas frente a desconexiones transitorias.

El SRE de guardia lo probó observando el ancho de banda de escritura del pool durante el “mover” y grepando logs de Samba buscando renombres.
Casi no hubo renombres. Fue una tormenta de copias. Mientras tanto, las snapshots en el dataset origen significaban que incluso después de la eliminación no volvió el espacio.
Los usuarios vieron un movimiento lento y sin recuperación de capacidad y concluyeron “el almacenamiento miente”.

La solución no fue un ajuste. Crearon una raíz de share única con subdirectorios para departamentos dentro de un dataset para flujos que requerían movimientos rápidos.
Mantuvieron datasets separados detrás para snapshots/retención, pero dejaron de exponer límites de dataset como shares separados para usuarios cotidianos. El cierre trimestral volvió a ser tranquilo. El servidor de archivos volvió a ser aburrido, que es
lo que quieres de un servidor de archivos.

Optimización que salió mal: “hagámoslo más duradero”

Otra organización había sufrido por una flota de portátiles que frecuentemente entraba en suspensión a mitad de copia. Oyeron sobre manejadores duraderos y decidieron
que lo correcto era aumentar la “seguridad” en todos lados. Habilitaron strict sync y trataron el servidor SMB como una base de datos. Nadie preguntó qué carga real tenían: archivos Office pequeños,
algo de CAD y enormes árboles de directorios.

El resultado fue un patrón extraño: las copias iban bien al principio, luego paradas periódicas. Los movimientos dentro de un dataset eran “casi instantáneos” pero a veces colgaban
durante decenas de segundos. Los usuarios notaron las pausas sobre todo durante grandes reorganizaciones de carpetas, que son operaciones intensivas en metadatos y renombrados.
Cada pausa correspondía a una ráfaga de operaciones metadatos tipo síncronas y a una pila de rupturas de lease mientras múltiples clientes navegaban los mismos árboles.

El equipo de almacenamiento persiguió discos. El equipo de red persiguió MTU. El equipo Windows persiguió actualizaciones de Explorer. El verdadero problema fue la política:
impusieron “durabilidad de base de datos” en un share general. La corrección no mejoró mucho (SMB ya tenía mecanismos de durabilidad),
pero la latencia empeoró. Revirtieron strict sync en shares generales, lo mantuvieron solo donde el negocio lo justificaba, y movieron datos críticos a un share con expectativas explícitas y ventanas de mantenimiento programadas.

Los manejadores duraderos no eran el villano. El villano fue pretender que todos los datos comparten las mismas semánticas de escritura. No las tienen.

Práctica aburrida pero correcta que salvó el día: diseño de límites y ventanas de cambio planificadas

Una empresa con un gran equipo de ingeniería tenía un trabajo semanal de “limpieza del sistema de archivos”: limpieza, archivo, reorganización.
Habían aprendido (a base de experiencia) que renombrados masivos en horario laboral crean tormentas de ruptura de lease y usuarios enojados.
Así que hicieron dos cosas aburridas.

Primero, diseñaron shares de modo que los movimientos más comunes se mantuvieran dentro de un dataset. “Proyecto activo” y “Archivo del proyecto” vivían en
el mismo dataset con una separación por directorio, no en datasets separados. La retención se manejaba con snapshots y políticas de replicación, no obligando a los usuarios
a mover entre sistemas de archivos.

Segundo, programaron cualquier migración entre datasets para una ventana, la anunciaron y la ratearon. Usaron una herramienta controlada en el lado del servidor (no arrastrar y soltar en Explorer)
para medir el comportamiento y evitar efectos de “manada” de docenas de clientes.

Una semana, un cambio de red causó desconexiones breves en una planta. Los portátiles se reconectaron. Los manejadores duraderos hicieron su trabajo. La tarea de migración continuó sin corrupción.
Los usuarios apenas notaron. El postmortem fue corto y aburrido, que es el mayor elogio en ops.

Chiste corto #2: Si quieres emoción, maneja una discoteca. Si quieres fiabilidad, maneja un servidor de archivos.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “Mover dentro del mismo servidor es tan lento como copiar”

Causa raíz: El movimiento cruza shares SMB o datasets ZFS, por lo que no puede ser un renombrado; Windows cae a copy+delete.

Solución: Coloca origen y destino dentro del mismo share y dataset para flujos comunes; o acepta que es una copia y dimensiona el sistema en consecuencia.

2) Síntoma: “Mover se cuelga al 99%”

Causa raíz: Manejadores abiertos o borrado demorado; Explorer espera la finalización de borrados/metadatos mientras otro cliente mantiene un lease/oplock.

Solución: Usa smbstatus --locks para identificar bloqueadores; rompe la dependencia (cierra la app, soluciona portátiles en suspensión, reduce watchers de directorio).

3) Síntoma: “Carpeta movida, pero aún aparece en la ubicación antigua”

Causa raíz: Caché del lado cliente, caché de enumeración de directorio, o actualización demorada por rupturas de lease.

Solución: Fuerza un refresco, confirma el espacio de nombres con ls en el servidor. Si es consistente en el servidor, trátalo como caché cliente. Si es inconsistente, revisa logs SMB para errores.

4) Síntoma: “Borramos terabytes pero no volvió el espacio”

Causa raíz: Las snapshots retienen bloques; los borrados solo eliminan referencias en vivo.

Solución: Inspecciona used/refer de snapshots; ajusta retención o mueve datos a un dataset con política de snapshots apropiada.

5) Síntoma: “Pausas aleatorias durante copiar/mover muchos archivos”

Causa raíz: Rupturas de lease/oplock; paradas por E/S de metadatos; presión de ARC; políticas síncronas de metadatos.

Solución: Correlaciona logs de Samba con iostat y estadísticas ARC. Reduce operaciones concurrentes en árboles y arregla la latencia de almacenamiento primero.

6) Síntoma: “Tras una caída de Wi‑Fi, la app sigue guardando, pero el renombrado falla”

Causa raíz: La reconexión del manejador duradero tuvo éxito, pero el renombrado subsecuente entra en conflicto con modos de compartición o un manejador competidor en la ruta de destino.

Solución: Revisa aperturas en origen y destino; considera cambios de flujo (guardar en temporal y luego renombrar atómicamente) y asegura que el servidor soporte IDs de archivo estables.

7) Síntoma: “Copiar es rápido, mover es lento (dentro del mismo dataset)”

Causa raíz: Mover dispara patrones rename/unlink que causan más rupturas de lease y updates de metadatos; copiar puede transmitir datos eficientemente.

Solución: Mide rupturas de lease y latencia de metadatos; programa reorganizaciones grandes y evita hacerlas mientras muchos clientes navegan el mismo árbol.

8) Síntoma: “Robocopy /Z funciona, Explorer falla”

Causa raíz: Diferente comportamiento del cliente. Robocopy usa modo reiniciable y semánticas de reintento distintas; Explorer es impulsado por UI y a veces más sensible a errores percibidos.

Solución: Para migraciones, usa herramientas robustas (Robocopy, herramientas del servidor) con flags explícitos; trata a Explorer como herramienta de conveniencia, no como sistema de migración.

Listas de comprobación / plan paso a paso

Checklist de diseño: prevenir sorpresas “mover se convirtió en copia”

1. Lista los 5 flujos de usuario principales que implican reorganizar datos (mover/renombrar).
2. Asegura que esos flujos se mantengan dentro de un único recurso SMB siempre que sea posible.
3. Asegura que esos flujos se mantengan dentro de un único dataset ZFS cuando “mover rápido” sea un requisito.
4. Usa datasets para política (snapshots/cuotas/replicación) donde no rompa flujos—o esconde los límites detrás de una raíz de share única.
5. Decide qué shares necesitan semánticas de durabilidad estrictas y cuáles necesitan throughput/latencia; documenta la decisión.

Checklist operativo: cuando los usuarios se quejan del comportamiento mover/copiar

1. Pregunta: ruta origen, ruta destino, conteo aproximado de archivos, tipos de archivo y si otros usuarios estaban navegando el árbol.
2. Comprueba si cruzó shares/datasets (Tarea 1, Tarea 3).
3. Comprueba si las escrituras del pool se dispararon durante el “mover” (Tarea 12).
4. Si es renombrado: revisa rupturas de lease y bloqueos (Tarea 5, Tarea 15).
5. Correlaciona con latencia de disco y presión de ARC (Tarea 8, Tarea 9).
6. Revisa snapshots si la queja incluye “borrar no liberó espacio” (Tarea 7).
7. Sólo tras tener evidencia, cambia una variable a la vez (opción de share, programación, layout de dataset).

Checklist de migraciones: mover datos entre datasets sin drama

1. Prefiere herramientas de transferencia del lado servidor durante una ventana de cambio; no confíes en Explorer para terabytes.
2. Limita concurrencia; los movimientos de archivos pequeños escalan mal con “más hilos” una vez que los metadatos son el cuello de botella.
3. Congela o coordina políticas de AV/indexación si puedes (o al menos anticipa la sobrecarga).
4. Mide: latencia de IOPS, rupturas de lease SMB y conteos de manejadores abiertos durante el movimiento.
5. Tener un plan de reversión: si las tormentas de lease impactan a usuarios, para la tarea limpiamente y reanuda después.

Preguntas frecuentes

1) ¿Los manejadores duraderos son una característica de ZFS?

No. Los manejadores duraderos son una característica del protocolo SMB implementada por el servidor SMB (a menudo Samba en sistemas Unix-like). ZFS influye en qué tan bien
el servidor puede mapear identidad de archivo estable y qué tan rápido completan las operaciones de metadatos.

2) ¿Por qué mover una carpeta a veces toma más que copiarla?

Porque mover un árbol de directorios puede ser una tormenta de renombres y borrados que dispara rupturas de lease y updates de metadatos. Una copia puede ser una
carga de streaming más suave si los clientes no compiten por el namespace.

3) Si desactivo los manejadores duraderos, ¿los movimientos volverán a la normalidad?

Usualmente no. Si tu “mover” en realidad es copy+delete por límites de share/dataset, desactivar manejadores duraderos no cambiará eso.
Si tu problema son rupturas de lease y retención de manejadores, desactivar durabilidad puede reducir estado pero también empeora la reconexión.
Arregla la arquitectura primero, luego afina.

4) ¿Por qué mover entre dos carpetas en el mismo share sigue pareciendo copia?

Dos carpetas aún pueden residir en datasets diferentes debido a puntos de montaje dentro de la ruta del share. La ruta parece continua; el sistema de archivos no lo es.
Confirma con zfs list -o mountpoint y el path = de tu share.

5) ¿Cuál es la relación entre leases SMB y “cuelgues”?

Cuando el servidor necesita que un cliente suelte una caché o vacíe escrituras pendientes, rompe el lease. Si el cliente responde lentamente
(suspensión, CPU saturada, AV), el servidor espera. Tu mover espera. Esa espera es la corrección haciendo su trabajo.

6) ¿Por qué Explorer muestra “calculando tiempo restante” para siempre?

Explorer tiene dificultades con cargas dominadas por metadatos y archivos pequeños, especialmente en red. También predice mal operaciones que cambian de naturaleza en vuelo
(renombrado tiene éxito para algunos archivos, fallback a copia para otros).

7) ¿Las snapshots ralentizan los movimientos SMB?

Las snapshots no suelen ralentizar el renombrado en sí. Afectan borrados y recuperación de espacio. Si mueves entre datasets (copy+delete), las snapshots en origen o destino
pueden cambiar la amplificación de escritura y los resultados de capacidad.

8) ¿Cómo pruebo ante la dirección que “mover se convirtió en copia”?

Muestra ancho de banda de escritura sostenido del pool durante un “mover” (Tarea 12). Luego muestra el límite de dataset o el mapeo cross-share (Tarea 1/3).
Los renombrados no generan grandes escrituras secuenciales; las copias sí.

9) ¿Es diferente en TrueNAS u otros appliances ZFS?

Los principios son iguales. El appliance puede exponer distintos ajustes o valores por defecto, pero las semánticas SMB no cambian: el renombrado es atómico solo dentro
del contexto de un sistema de archivos/share; los manejadores duraderos y leases siguen requiriendo seguimiento de estado y coordinación.

10) ¿Qué debo cambiar primero: afinado de ZFS o de Samba?

Ninguno de los dos. Cambia el layout primero: mantiene movimientos comunes dentro de un dataset/share. Luego mide. Solo afina tras identificar un cuello de botella específico:
latencia de metadatos, contención de bloqueos o política de escrituras síncronas.

Próximos pasos que deberías hacer

Si quieres que copiar/mover deje de sentirse raro, deja de tratarlo como un misterio y empieza a tratarlo como un problema de clasificación:
¿renombrado o copia? Una vez lo sepas, la solución se vuelve obvia y por lo general aburrida.

1. Inventario tus shares y datasets y dibuja un mapa de límites que los usuarios no puedan cruzar accidentalmente durante flujos normales.
2. Elige una “zona de mover rápido” (dataset único, raíz de share única) para equipos que reorganizan constantemente.
3. Instrumenta rupturas de lease y bloqueos (sube brevemente niveles de log durante incidentes) para poder diferenciar “contención cliente” de “latencia de almacenamiento”.
4. Programa reorganizaciones grandes y migraciones fuera de horas pico, y usa herramientas controladas en servidor en lugar de Explorer.
5. Alinea la política de snapshots con la realidad: si la empresa espera que el espacio vuelva inmediatamente, no mantengas snapshots de larga duración en ese dataset.

Los manejadores duraderos están haciendo trabajo de fiabilidad que no quieres hacer manualmente. Déjalos. Solo no diseñes un layout de share/dataset que
obligue a cada “mover” a convertirse en una copia y luego te sorprendas cuando la física aparezca.