12 de enero de 2009

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)

9 comentarios:

  1. Muy didáctico.

    dos cosas offtopic:
    - trabajas en algo referente al kernel (drivers o algo similar) ?
    - el sistema de comentarios que tiene no me permite suscribirme por correo como normalmente me deja blogger :/

    ResponderEliminar
  2. rectifico: sí me deja suscribirme, lo he visto después :)

    ResponderEliminar
  3. javi: No trabajo en el kernel, pero es un mundillo que me gusta seguir de cerca

    ResponderEliminar
  4. Muy buen post!

    En concreto, ¿Por qué esa obsesión de no hacer una herramienta de recuperación tanto en XFS como en ZFS? Es raro que alguien pueda llegar a pensar que exista sistema alguno que no falle nunca o que se pueda llegar a controlar todos los fallos. Sobretodo si el sistema es algo complejo como no deja de serlo un sistema de archivos.

    Curiosa y grave cagada de estos chicos de Sun que se extenderá a los BSD, incluido OSX, si no la corrigen. Porque se puede corregir, ¿no?

    ResponderEliminar
  5. underme: Es propio de todo ingeniero con buscar soluciones perfectas a todo, y es muy humano caer en tentaciones del tipo "voy a hacer que mi FS no necesite ningún fsck y así dar un gran paso", hasta se diría que es bueno (si un ingeniero no se plantera cosas así eso, ¿que otras cosas no estará dejando de plantearse? Tal vez para que hayan surgido cosas como ZFS haya sido necesario cometer errores menores como el del fsck).

    A mi no me cabe ninguna duda que quienes hicieron ZFS se darían cuenta del error que supone no tener un fsck si en vez de estar diseñandolo ellos, lo estuvieran haciendo otros y ellos tuvieran que opinar.

    ResponderEliminar
  6. Anónimo10:21 a. m.

    Diego, excelente entrada. Da gusto leerla y es muy didáctica. ¡ Enhorabuena !

    ResponderEliminar
  7. Anónimo5:04 p. m.

    Bueno, eso de no borrar el archivo anterior mientras se trabaja con el nuevo es algo que, si bien no hacia exactamente asi, ya tenia el viejo y queridisimo VMS, en este SO se podia configurar CUANTOS BACKUPS de los archivos querias qeu qudaran (los cuales se nombraban con ;# al final incrementandose y referenciandose siempre al ultimo si no se especificaba este parametro).

    Una vez mas se recicla una vieja idea como la panacea de la evolucion!

    (Vamos que la vieja triada Digital,Intel,Xerox ya inventaron todo :-) )

    ResponderEliminar
  8. Anónimo12:46 a. m.

    http://opensolaris.org/os/community/zfs/faq/#whynofsck

    "[...] During the 5 years of ZFS development, no such pattern has been seen.[...]"

    ResponderEliminar