Cuando un HC620 de helio con SMR se usa con F2FS, síntomas como congelamientos del sistema, aplicaciones sin respuesta y iowait alto durante mucho tiempo normalmente no se deben a una sola opción mal configurada. Son el resultado de un choque entre las características del dispositivo y la política del filesystem.

Western Digital Ultrastar DC HC620 es un disco Host-managed SMR. Encaja mejor con escrituras secuenciales, cargas zoned-aware y stacks de software que entienden las restricciones del dispositivo. F2FS es un filesystem log-structured diseñado para flash. Aunque puede reorganizar muchas escrituras aleatorias como escrituras secuenciales, la falta de espacio libre, el GC frecuente o las actualizaciones intensas de metadata pueden llevar a un disco mecánico SMR a ciclos internos largos de mantenimiento.

Primero confirma si es este problema

Empieza con estas comprobaciones:

1
2
3

iostat -x 1
iotop -oPa
dmesg -T | grep -Ei "f2fs|blk|zoned|reset|timeout|I/O error"

Si %util se mantiene cerca de 100%, await es alto y muchos procesos quedan en estado D, el cuello de botella probablemente está en el I/O del dispositivo de bloques.

Luego confirma si el disco aparece como dispositivo zoned:

1
2

lsblk -o NAME,MODEL,SIZE,ROTA,ZONED,SCHED,MOUNTPOINTS
cat /sys/block/sdX/queue/zoned

Si es Host-managed SMR, un filesystem normal y cargas con escrituras aleatorias pueden rendir muy mal. A diferencia de muchos SMR de escritorio gestionados por el propio disco, esta clase depende más de que el software del host entienda las reglas de escritura.

Por qué F2FS puede amplificar el bloqueo

El problema de SMR es que no puede sobrescribir ubicaciones arbitrarias tan libremente como un disco CMR. Las pistas se superponen para aumentar capacidad. Cuando las escrituras se vuelven aleatorias, las sobrescrituras son frecuentes o la caché se agota, el disco necesita mover y reorganizar datos.

F2FS fue creado para NAND flash. Usa escrituras log-structured y recupera espacio mediante segment cleaning y garbage collection. En SSD esto suele ser natural porque no hay seek mecánico. En discos mecánicos, especialmente SMR, las lecturas y escrituras generadas por GC pueden convertirse en tail latency severa.

Cuando background GC de F2FS, escrituras foreground, checkpoints, actualizaciones de metadata y la limpieza SMR interna del disco se superponen, la cola de I/O puede permanecer saturada durante mucho tiempo. En espacio de usuario, copiar archivos, borrar directorios, descargar, descomprimir o escribir en bases de datos puede hacer que el sistema parezca congelado.

Empieza con opciones de montaje conservadoras

Si no puedes migrar inmediatamente, ajusta primero /etc/fstab:

1

UUID=xxxx  /data  f2fs  defaults,nodiscard,active_logs=2,gc_merge,flush_merge,lazytime  0  0

Qué hace cada opción:

• nodiscard: desactiva discard en tiempo real. Los discos mecánicos normalmente no necesitan TRIM/discard frecuente como un SSD.
• active_logs=2: F2FS admite 2, 4 o 6 active logs; el valor por defecto suele ser 6. Bajar a 2 puede reducir presión de seek por logs concurrentes.
• gc_merge: permite que el hilo de background GC gestione algunas peticiones de foreground GC, reduciendo bloqueos cuando un proceso dispara GC lento.
• flush_merge: fusiona peticiones de cache flush, útil si el dispositivo maneja flush lentamente.
• lazytime: reduce escrituras de metadata causadas por algunas actualizaciones de tiempo de acceso.

No trates checkpoint=disable como una opción normal de rendimiento. Puede reducir presión de checkpoint, pero aumenta el riesgo tras cortes de energía o fallos. La documentación del kernel también indica que el filesystem sigue necesitando GC mientras checkpoint está desactivado para garantizar espacio utilizable. Si no entiendes bien el coste, no lo uses como solución permanente.

Ajusta el I/O scheduler

Los discos mecánicos y SMR suelen necesitar fusión de peticiones y control de latencia. Mira primero el scheduler actual:

1

cat /sys/block/sdX/queue/scheduler

Puedes probar mq-deadline:

1

echo mq-deadline | sudo tee /sys/block/sdX/queue/scheduler

Para uso de escritorio, también merece probar bfq. No mires solo throughput secuencial. Observa si bajan los bloqueos, si await mejora y si el sistema se siente más estable.

Limita el background GC de F2FS

La ruta sysfs de F2FS depende del nombre real del dispositivo. Compruébalo primero:

1

ls /sys/fs/f2fs/

Luego ajusta el intervalo de GC para el dispositivo correspondiente:

1
2

echo 60000 | sudo tee /sys/fs/f2fs/sdX/gc_min_sleep_time
echo 120000 | sudo tee /sys/fs/f2fs/sdX/gc_max_sleep_time

Aquí sdX es solo un ejemplo. El nombre real puede ser sda1, dm-0 u otro. Aumentar GC sleep time reduce la frecuencia con la que background GC compite por I/O, pero la recuperación de espacio será más lenta. Si el disco está casi lleno, puede volver a dispararse foreground GC, así que conviene dejar espacio libre suficiente.

Mejores opciones a largo plazo

Si el disco guarda datos importantes, la opción más segura a largo plazo es hacer backup y cambiar de filesystem, o usar un disco más adecuado.

Para discos mecánicos grandes, considera:

• XFS: adecuado para archivos grandes, discos de backup, bibliotecas multimedia, archivos y escrituras secuenciales.
• EXT4: compatible, estable y con mucha documentación de diagnóstico.

Si el disco es Host-managed SMR, confirma también que kernel, controlador, filesystem y aplicaciones soportan realmente zoned block devices. De lo contrario, usarlo como un disco normal de escrituras aleatorias puede provocar bloqueos largos e impredecibles.

Consejos prácticos

Este tipo de disco encaja mejor con datos fríos, archivos, backups, multimedia y escrituras secuenciales. No es buena opción para cachés de descarga, imágenes de contenedores, discos de VM, bases de datos, descompresión frecuente o escrituras aleatorias de archivos pequeños.

Si debes seguir usando F2FS, al menos haz esto:

• Desactiva discard en tiempo real.
• Usa active_logs=2 para reducir logs concurrentes.
• Activa gc_merge y flush_merge.
• Mantén bastante espacio libre.
• Evita colocar descargas, bases de datos e imágenes de VM en este disco.
• Observa iostat -x 1, no solo la velocidad media.

En resumen, los congelamientos de HC620 + F2FS aparecen cuando se combinan las restricciones de escritura de SMR, el GC de F2FS y la tail latency de un disco mecánico. La mitigación a corto plazo es ajustar opciones de montaje, scheduler y background GC. La solución a largo plazo es migrar a XFS/EXT4 o usar el SMR solo para cargas secuenciales de archivo.

Referencias:

• Linux Kernel Documentation: F2FS
• Western Digital Ultrastar DC HC620 Data Sheet