14 de enero de 2012

FreeBSD 9.0 y el retorno de softupdates

Ya ha salido FreeBSD 9.0, lo cual quiere decir que es un momento propicio para renovar mi gratuito e injustificado desdén linuxero hacia los BSDs.

Aunque en los foros los usuarios de FreeBSD suelen nombrar a ZFS como una ventaja de usar FreeBSD, y con razón, hay que recordar que desde el punto de vista de los desarrolladores la cosa cambia. La mayoría de ellos son militantes que creen que la licencia BSD es la mejor y sienten desprecio (cuando no odian abiertamente) la GPL. Es más, su plan para FreeBSD 10 es erradicar por completo cualquier línea de código GPL de la base del sistema. Por esta razón, no es sorprendente que no sientan un amor incondicional por ZFS, que está licenciado bajo la CDDL. Por muchas cualidades que tenga, se trata de un sistema de archivos no BSD.

Así que, lejos de adoptar ZFS como sistema de archivos definitivo, siguen mejorando su UFS. Y una de las mejoras más curiosas de 9.0 es una curiosa mezcla de softupdates + journaling.

Softupdates consiste en que toda escritura a disco se ordene previamente en memoria respecto a todas las pendientes, más las que vengan, de modo que siempre se mantenga la coherencia del sistema de archivos sin necesidad de fsck ni journaling. En teoría es una idea sencilla, en la práctica la implementación requiere una complejidad brutal. Se requiere introducir un sistema de mantenimiento de dependencias cuya complejidad no se puede abstraer tras una API, es esa clase de complejidad que se extiende como un vertido de petróleo a toda la implementación del sistema de archivos, requiriendo en cada operación lidiar manualmente con las clases de dependencia, sus estados, operaciones de "roll back" y "roll forward"...todo eso añadido a la complejidad del propio sistema de archivos, que no es poca. Si quieren, puede intentar leer este artículo de LWN sobre el tema, donde una mujer que trabajó en inventar ZFS reconoce su incapacidad para entenderlo por completo.

Y, tras lidiar con toda esta complejidad, resulta que softupdates no es capaz de acabar con todas las incoherencias que puedan ocurrir. Existen una serie de incoherencias benignas que no impiden el uso normal del sistema de archivos (bloques marcados como usados que en realidad están libres), pero requieren un fsck. El fsck se puede ejecutar "de fondo", sin necesidad de esperar a que termine para montar el sistema de archivos, pero el I/O y CPU necesarios para escanear todo el sistema de archivos no se los quita nadie.

Por eso no debe sorprender que al final mucha gente acabara pasando de este sistema y pidiera journaling. Como los BSDs son así, ni tan siquiera para añadir journaling se pusieron de acuerdo, así que FreeBSD añadió una cosa llamada "gjournal" (implementado a nivel de gestor de volúmenes, no del sistema de archivos - no me pregunten por qué) y NetBSD una cosa llamada WAPBL.

Pues bien, en FreeBSD 9.0 han decidido ir más allá. Se trata de un micro-journal que hace journaling de las pocas operaciones cuya coherencia softupdates no era capaz de garantizar. De ese modo, en pleno 2011, FreeBSD puede tener softupdates sin necesidad de fsck de fondo posterior, todo ello gracias a la implementación del mismo mecanismo que softupdates trataba de evitar. ¡Albricias! Todo esto para un sistema de archivos que no soporta ninguna de las características avanzadas de ZFS, y que no les quita de encima la necesidad de implementar un sistema de archivos de nueva generación con licencia BSD.

La próxima vez que vean un comentario BSDero hablando de lo chapuceros que son en Linux, acuérdense de esto.

4 comentarios:

  1. Otro ejemplo de como por creer que una solución es la correcta se añade complejidad que hace que sea de todo menos la más práctica y eficiente. Es un problema que siempre han tenido en FreeBSD, se centran en soluciones teóricas ideales y cuando se implementan son de todo menos ideales. BTW, en algo si que les admiro: la capacidad de realizar cambios sustanciales en el sistema base como la migración a LLVM que están haciendo :)

    ResponderEliminar
  2. ¿Sabéis si actualmente Btrfs es un sustituto fiable y funcional de Zfs? ¿O todavía le falta mucho? Gracias

    ResponderEliminar
  3. juanman3:37 p. m.

    Btrfs es solo un sistema de archivos...
    ZFS es mucho mas que eso, tiene integrado el gestor de volumenes logicos, lo que le permite implementar varias funcionalidades mas...

    ResponderEliminar
  4. Ramón Rey: Si, lo de LLVM está bien. Lo malo es que si LLVM fuera GPL y GCC BSD, en lugar de promoverlo lo boicotearían xD

    Osqui: Hay que esperar a que haya un fsck y sea adoptado por una gran distro.

    juanman: Btrfs tiene la misma gestión unificada de volúmenes que ZFS.

    ResponderEliminar