¿Cuándo es fsck peligroso?

37

Recientemente, he visto que el sistema de archivos raíz de una máquina en un centro de datos remoto se vuelve a montar de solo lectura, como resultado de problemas de coherencia.

Al reiniciar, se mostró este error:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

Después de ejecutar fsck como se sugiere, y aceptar las correcciones manualmente con Y, los errores se corrigieron y el sistema ahora está bien.

Ahora, creo que sería interesante si fsck estuviera configurado para ejecutar y reparar todo automáticamente, ya que la única alternativa en algunos casos (como esta) es ir en persona al centro de datos remoto y conectar una consola a la máquina afectada.

Mi pregunta es: ¿por qué fsck por defecto pide intervención manual? ¿Cómo y cuándo una corrección realizada por dicho programa sería insegura? ¿Cuáles son los casos en que el administrador del sistema puede querer dejar de lado una corrección sugerida por un tiempo (para realizar otras operaciones) o abortarla por completo?

— scristalli
fuente

15

Si los desarrolladores estuvieran 100% seguros de que el error podría repararse automáticamente, entonces no sería un error en primer lugar.

— user253751

42

fsckdefinitivamente causa más daño que bien si el hardware subyacente está dañado de alguna manera; CPU defectuosa, RAM defectuosa, un disco duro agonizante, un controlador de disco dañado ... en esos casos es inevitable más corrupción.

En caso de duda, es una buena idea simplemente tomar una imagen del disco dañado con dd_rescuealguna otra herramienta, y luego ver si puede corregir esa imagen con éxito. De esa manera, todavía tiene disponible la configuración original.

— Janne Pikkarainen
fuente

44

He trabajado mucho con el hardware defectuoso y estoy de acuerdo con esto. Lo último que quiero hacer es fsck si sospecha que hay algún hardware defectuoso de algún tipo. También he visto un evento de baja potencia y una recuperación posterior que se retrasó enormemente por fsck automático.

— jorfus

Para dar un ejemplo concreto: he trabajado en una máquina con un controlador de disco que "al azar" (aproximadamente 1 vez en 10 ^ 5) convertiría una lectura o una escritura para bloquear XXXXXXYY en cualquier dispositivo a una escritura para bloquear 000000YY en el primer dispositivo Es decir, frecuentemente enviaba datos estructurados incorrectos y no estructurados al sector de arranque y a varias estructuras críticas del sistema de archivos del disco de arranque. Ejecutar fsck en tal situación (millones de lecturas) puede eliminar cualquier posibilidad restante de recuperar datos.

— Eric Towers

2

1 en 10 ^ 5 es mucho ... eso es 10 bytes cada vez Mb.

— Nelson

1

@ Nelson: Es como ... La unidad allí es "transferencias de bloque único", no "bytes". Por lo tanto, diez escrituras de bloque defectuosas por millón de bloques (y los bloques son significativamente más grandes que los bytes).

— Eric Towers

21

Has visto un ejemplo donde fsckfuncionó, pero he visto más que suficientes sistemas de archivos dañados donde no funcionó con éxito en absoluto. Si funcionara completamente automático, es posible que no tenga la oportunidad de hacer cosas como ddvolcar un disco o algo así, lo que en muchos casos sería una excelente idea antes de intentar una reparación.

Es nunca, nunca una buena idea para intentar algo así automática en absoluto.

Ah, y los servidores modernos deberían tener consolas remotas o, al menos, sistemas de rescate independientes para recuperarse de algo así sin cargar un bastidor KVM en el servidor.

— Sven
fuente

77

En realidad, lo que no es una buena idea es decir " nunca, nunca " así, cuando no es cierto. Caso de uso donde es una buena idea: las particiones principales del servidor se pueden volver a crear desde cero bastante rápido, en caso de problemas. En realidad, se accede a los datos importantes a través de un sistema de archivos remoto, con la redundancia adecuada para esos datos. Prefiero arriesgarme fsck -p /y fsck -p /var, etc., trabajar bien y poner en funcionamiento el servidor sin intervención manual, y arriesgar el pequeño, no cero% de posibilidades de una catástrofe mayor en esas particiones que puedo recrear si es necesario .

— TOOGAM

1

Si el sistema se puede reinstalar fácilmente, simplemente hago eso ...

— Sven

1

Eso llevaría más tiempo. Las opciones son: A) Riesgo de hacerlo automáticamente. B) Haga que alguien le diga fsckque se atienda, y luego todo funciona bien Tarda unos 2 minutos, si eso. Tiempo de inactividad hasta que esto suceda. C) Haga que alguien reinstale el sistema operativo. Toma más de 30 minutos. ¿Estás eligiendo la opción C? Tal vez una diferencia clave que tenemos es que he tenido fscktrabajo un mayor porcentaje del tiempo de lo que usted cita en su respuesta. Mi punto principal no era el diseño del sistema (este sistema barato no usa una consola remota), sino que decir " nunca, nunca " era una frase demasiado fuerte para ser precisa

— TOOGAM

Solo aceptemos estar en desacuerdo.

— Sven

0

En primer lugar, debe comprender que con los sistemas de archivos modernos (periodizados), un bloqueo del sistema no dañará el sistema de archivos y no se requerirá fsck en el momento del arranque.

Ext3, Ext4, ZFS, btrfs, xfs y todos los FS modernos son 100% consistentes después de un bloqueo o reinicio del sistema.

FS no periodizados como ext2 o vfat son un gran NOGO para un sistema rootfs.

Ahora, si su sistema requiere un fsck en el momento del arranque, debe preguntarse: ¿cuál fue la razón de esto en primer lugar?

Luego debe investigar los registros de su kernel para averiguar cuándo y qué sucedió. También debe retroceder en el tiempo en los registros para buscar desde cuándo comenzó el error. Debe verificar sus discos con smartctl. Etc ... Si necesita un fsck en un fs registrado, es prácticamente seguro que su hardware está fallando, suponiendo que el fs no haya sido dañado por un administrador (con herramientas de nivel de bloque como dd) o por un error.

Por lo tanto, es una tontería usar fsck para "solucionar" el problema sin investigar y solucionar la causa raíz (reemplazando / actualizando el hardware / firmware / software defectuoso).

Hacer un fsck, completar el arranque y ser feliz es ingenuo por decir lo menos. Afirmar que "he tenido un trabajo fsck un mayor porcentaje del tiempo de lo que usted cita" me hace preguntarme qué quiere decir con "trabajo fsck". fsck puede haber devuelto su fs a un estado consistente al perder algunos archivos y datos en el proceso ... ¿Se comparó con una copia de seguridad? Muchas personas pierden archivos u obtienen datos corruptos sin darse cuenta ...

— Francois Scheurer
fuente