¿Cuánto tiempo puede durar fsck en un volumen de 30 TB?

A mediados de noviembre, un VPS que estoy alquilando de una empresa de hosting dejó de responder. Cuando contacté con el soporte, me explicaron que un corte de energía en el centro de datos provocó un reinicio forzado y fsck. Finalmente, pregunté por qué estaba tardando tanto y me dijeron que el tamaño del volumen es de 30 TB. La última vez que recibí una actualización fue en febrero, y no respondieron a mi consulta más reciente.

Entiendo que fsck puede ser muy lento para algunos sistemas de archivos, pero es posible que fsck demore 6 meses en un volumen de 30 TB, o debo suponer que esta empresa de hosting me está mintiendo para que continúe pagando mi factura cada ¿mes?

fsckla velocidad depende principalmente de la cantidad de archivos y de cómo se distribuyen en el directorio respectivo. Dicho esto, 6 meses para un fsckes absolutamente absurdo: debería haberse completado en algunas horas como máximo, especialmente si se usa el xfsque tiene la xfs_repairutilidad rápida . Aquí puede encontrar algunos fsckrecorridos a escala, todos completados en menos de una hora (3600). Por lo tanto, no es posible que fscktodavía se esté ejecutando.

De todos modos, una pérdida de potencia inesperada no causará un golpe completo fsck, sino solo una repetición de diario muy rápida (algunos segundos) . Sin embargo, si algunos archivos clave se dañaron, el sistema operativo puede no arrancarse.

Pero probablemente solo te mintieron. Debe dejar de pagar de inmediato, solicitar una explicación y solicitar un reembolso total.

Conjetura: Su sistema utiliza un RAID sin BBU / FBWC (o incluso RAID de software) con todos los cachés de escritura posibles (incluidos estos en los propios discos duros) configurados en sus configuraciones más agresivas, para obtener el máximo rendimiento a un costo mínimo. Un corte de energía en una configuración de este tipo puede dejar un sistema de archivos de registro en una condición en la que no se puede confiar en el registro y no se puede usar para la recuperación. El problema es que dicho sistema reordena y pospone agresivamente las escrituras, lo que significa que se puede escribir una entrada de diario con el efecto de perder la acción de datos ... o la entrada de diario se pierde en una acción de datos que fue consecuente.

Recuperar dicho sistema de una interrupción en el peor de los casos puede significar que tiene que hacer un fsck / reparación "lento" que realmente examina todas las estructuras del sistema de archivos tal como están, lo que de hecho podría tomar uno o dos días para 30 TB ... y No es improbable que deba ejecutar varios ciclos de reparación. Agregue a eso que el personal podría no estar siempre disponible para monitorear esto, fácilmente podría reducirse a un fsck por semana. Probablemente se rindieron y olvidaron.

Para la mayoría de los sistemas de archivos, será mucho más rápido, incluso cuando haya errores, ya que normalmente solo se verifican los metadatos.

En el peor de los casos, puede leer todo el disco ( por ejemplo, algo así como fsck.ext4 -cc /dev/sdauna prueba de escritura no destructiva en cada bloque), que podría tomar unos días para 30 TB. Si conoce la velocidad de las unidades, puede calcular el tamaño / velocidad . Para un disco duro de consumo con aproximadamente 100 MB / s copiando, unos pocos TB pueden llevar más horas de lo que la mayoría de la gente esperaría.

Si fuera su servidor, podría tener el problema de que se inicia y luego se cuelga cuando fsckle pregunta si desea corregir un error. Pero el administrador del centro de datos no dejará una fscksuspensión durante 6 meses mientras todos los VPS estén desconectados.

Entonces, o te están mintiendo, o hay un gran malentendido. O estaban ejecutando fsck hace algún tiempo y no lo actualizaron sobre el nuevo problema después de que terminó.