Historias repetidas: El error de no tener un fsck

Una de los objetivos de los creadores de ZFS fue no hacer un fsck para su nuevo sistema de archivos. La justificación oficial: "ZFS no necesita fsck"...es decir, que ZFS ha sido diseñado explicitamente para no necesitar fsck. ¿Se puede decir varios años despues que ha sido una buena decisión no tener un fsck? Para justificar un "no" como respuesta he escrito este post, asi que sigan leyendo...

Una de las características principales de ZFS es que la estructura en el disco del sistema de archivos se mantiene siempre, siempre, siempre válida. Da igual en qué momento quites el cable de la luz al ordenador mientras lo usas: ZFS te garantiza que, escojas el momento que escojas para tirar del cable, la estructura del sistema de archivos será siempre válida. Es técnicamente imposible encontrar un momento en el que sea posible tirar del cable y encontrar algún problema. No se trata de journaling: Un sistema de archivos con journaling si que deja el sistema de archivos en estados inconsistentes, pero deja un "journal" de operaciones no finalizadas que permite reparar esas inconsistencias en pocos segundos. ZFS jamás puede llegar a un estado de inconsistencia, por eso no usa journaling: no lo necesita (y se gana algo de rendimiento con ello).

ZFS consigue que sea así porque los cambios al sistema de archivos se hacen de forma transaccional: Cuando modificas un archivo, a diferencia de un sistema de archivos tradicional, que trata de reescribir los datos antiguos, lo que se hace es escribir el archivo modificado a una parte del disco que no esté siendo utilizada, y una vez que está escrito ese archivo, se modifica de forma atómica el "puntero" que apuntaba al viejo archivo hacia el nuevo. Esa modificación o se lleva a cabo o no, nunca se queda a la mitad, Por eso, escojas el momento que escojas para tirar del cable, el sistema de archivos se quedará apuntando al viejo archivo o al nuevo, pero no habrá inconsistencias. Por eso, jamás se reescriben los bloques utilizados por el archivo viejo, se escriben siempre en un sitio nuevo y vacío (algo que, por cierto, implica fragmentación).

Si unimos esto el checksumming que se mantienen de todas las estructuras de datos del disco y el Raid-Z con autocuración, se entiende por qué se asegura que ZFS "no necesita fsck". En una configuración Raid-Z todo el sistema de archivos está duplicado en más de un sistema de archivos -incluso puede activarse la duplicación dentro de un mismo sistema de archivos-, y si se encuentra un fallo al comprobar el checksum, se sabe que ha ocurrido un error y se corrige con una de las copias. Si por pura paranoia se necesita comprobar si el sistema de archivos está limpio se recurre al scrubbing, es decir, comprobación de todos los checksums.

Gracias a estos sistemas, y a las horripilantes torturas a las que han sometido al código (por lo visto tienen una suite de tests magnífica), los diseñadores de ZFS afirman que "no necesita fsck", era uno de sus propósitos librarse de lo que para ellos es una reliquia innecesaria para un sistema de archivos decente. Los fallos de hardware se detectan gracias al checksum y se solucionan usando una de las copias...los fallos de software se excluyen como posibilidad porque se asumen unos altos estándares de calidad y porque de todos modos, de haber uno, será detectado gracias a los checksums, solucionado rápidamente y suministrado a los canales de actualización de software, lo cual garantiza que a largo plazo se solucionarán todos...los fallos "lógicos" tambien están excluidos por lo mencionado al principio....y las meteduras de pata por parte del usuario no son problema suyo: Conclusión, no se necesita fsck. Pero....

El mundo real es muy perro. Como era de esperar, han aparecido algunos casos de corrupción de sistemas de archivos ZFS. Casos que sin duda serán raros, rarísimos de encontrar, y mucho más de padecer. Pero ahí están.

Y, ¿qué pueden hacer esos usuarios con su sistema de archivos ZFS corrupto?...Nada. No pueden hacer nada: Puesto que los diseñadores de ZFS han llegado a la conclusión de que la corrupción es Algo Que No Puede Ocurrir (tm), al encontrarse con una no tienen ninguna manera de darle solución. La única opción que tiene el usuario es reformatear y usar una copia de seguridad, si fuistes lo suficientemente precavido como para tenerla (que deberías serlo), y si fuistes tan inocente como para usar los snapshots de ZFS como copias de seguridad ya puedes darte por jodido. Como no hay fsck, esos usuarios no pueden reparar sus sistemas de archivos, ni tan siquiera pueden tratar de extraer los datos (que es otra de las funciones del fsck). No se pueden leer los datos, ni tan siquiera los no corruptos, porque ni tan siquiera pueden montar el sistema de archivos. No pueden construir como auxilio de emergencia una herramienta que trate de leer el formato ZFS por la simple razón de que el formato se ha corrompido y la herramienta no podrá leerlo - si no, el sistema de archivos hubiera podido montarlo.

Y aun ignorando estos fallos en configuraciones normales, hay que tener en cuenta que los checksums de ZFS son desactivables, y que aunque es posible activar la replicación de datos en un mismo sistema de archivos mucha gente no lo va a hacer porque reduce la capacidad a la mitad, y por tanto se detectarán los fallos pero al no haber copias no se podrán solucionar...hay configuraciones válidas en las que se puede prescindir de lo que protege a ZFS de no necesitar, teóricamente, un fsck. La conclusión es que el precio de no necesitar fsck, tan solo teóricamente, es, de entrada, reducir a la mitad el espacio de almacenamiento para duplicar todas las estructuras del sistema de archivos. Y aun si las duplicas, como se ha visto, puede pasarte tambien...

Quizás digan algunos que esos son "casos extremos". Si, lo son. La mayoría de la gente no tenía grandes problemas de corrupción ni tan siquiera con FAT en Win9x. En el resto de sistemas de archivo que si tienen fsck la necesidad de utilizarlo es muy remota, solo en "casos extremos". Y aunque ZFS puede tener fallos en "casos extremos", es obvio que los checksums y la duplicación con autocuración reducen en gran medida la posibilidad de que esos casos ocurran. Pero no los eliminan....y cuando ocurren, un usuario esperará siempre un buen fsck que pueda lograr algo.

El título del post menciona a una historia repetida. La historia es la de otro sistema de archivos que, al ser estrenado, los equipos de marketing lo vendieron como un sistema de archivos que "no necesita fsck": al fin y al cabo, los sistemas de archivos con journaling tambien mantienen siempre la consistencia del disco y teóricamente no necesitan fsck. Ese sistema de archivos era XFS. Pero frente a los casos teóricos, se impuso la cruda y dura realidad: A veces, se necesita un fsck. A veces, es imprescindible un fsck. SGI se vió obligada a crear un fsck, y con él, a comerse su propio marketing. Tarde o temprano, Sun tambien se verá obligado a lo mismo. Al fin y al cabo, ¿pondrían ustedes sus datos en manos de un sistema de archivos que, como recurso extremo, solo puede responderte un "vaya, eso no debería haber ocurrido", "vaya, debería haber utilizado la mitad de su espacio de almacenamiento para duplicar todas las estructuras del sistema de archivos"... o en manos de uno que te ofrece un fsck, aunque sea malo?

(Como nota final, señalar que btrfs, la copia de ZFS para Linux, tiene como uno de sus principales objetivos no solamente crear un fsck, sino hacerlo extremadamente potente)