Progreso de BTRFS

El desarrollo de BTRFS (un sistema de archivos para Linux actualmente en desarrollo) no está parado, ni tan siquiera está siendo lento. Me entero por este blog de que Chris Mason acaba de añadir soporte para que un sistema de archivos BTRFS pueda estar formado por varios "volúmenes" situados en diferentes dispositivos.

Esto es exactamente lo mismo que permiten hacer LVM y otros "gestores de volúmenes", y por eso puede parecer poco innovador, pero es lo que ha hecho que ZFS tenga el éxito que tiene: integración de los volúmenes y el sistema de archivos en uno. Para poder implementarlo correctamente, las estructuras de datos del sistema de archivos pueden tener referencias no solo a lo que hay en el sistema de archivos (ej: "los datos de tal archivo están en tal sitio"), sino que tambien hay espacio para incluir un "puntero" que "apunte" a otro volumen (ej: "los datos de tal archivo están en en tal sitio de tal volumen").

Una de las cosas que pronto permitirá hacer BTRFS es un modo RAID que los de ZFS llamaron RAID-Z, similar al RAID 5 pero mucho más rapido y fiable. Al soportar BTRFS checksumming a nivel de bloque, cualquier corrupción de datos -incluso antes de que el disco duro notifique de un fallo de lectura- será detectado inmediatamente. Añadiendo otro disco duro como mirror, al detectarse ese error el sistema de archivos puede recuperar la copia no corrupta del segundo disco duro, pero aun más: tambien puede corregir automáticamente el fallo en el disco corrupto (algo imposible en un RAID, pues no tiene conocimiento del sistema de archivos y por tanto no puede relocalizar partes del sistema de archivos de un lado a otro). Todo esto con una interfaz de usuario sencillísima. Por el precio de una unidad adicional y un par de comandos ganas una fiabilidad y un rendimiento que por lo visto ningún producto RAID actual, sea hardware o software, puede ofrecer, en gran medida por la integración "sistema de archivos-volumen".

Pero hay más. Chris Mason tambien ha anunciado CRFS, un protocolo de red competidor de NFS, mucho más rápido, basado en BTRFS. Personalmente soy bastante escéptico en este último punto: Al estar integrado íntimamente con el formato de disco de BTRFS, no tiene pinta de tener un buen diseño. Es decir, estas cosas deberían ser, hasta cierto punto, agnósticos en temas de formatos. Pero quien sabe, lo mismo se podría haber dicho de los gestores de volúmenes cuando apareció ZFS. Por citar ventajas, CRFS soporta el tema de los snapshots ligeros y rápidos de BTRFS, cosa que no creo que NFS soporte y si lo soporta no creo que lo soporte de manera muy eficiente, por la misma razón que los snapshots de LVM no son tan eficientes como los de BTRFS. En cualquier caso es interesante porque parece que deja a NFS en vergüenza en cuanto a rendimiento.

Y la cosa no acaba ahí. En los últimos meses, a BTRFS le han añadido la capacidad de redimensionarse en vivo, soporte de tamaños de bloque superiores al de la página de la arquitectura (4KB en x86), atributos extendidos (aka xattrs), un programa conversor que permite cambiar un sistema de archivos ext3 existente al formato de BTRFS que comparte (!) los datos entre el formato de ext3 y BTRFS (crea las estructuras de BTRFS en el espacio libre de ext3), soporte de data=ordered, "barreras" (sincronización de las operaciones con la unidad de disco), y "referencias inversas" (es decir, que los datos de un archivo tienen un "puntero" al inodo con el que están relacionado, del mismo que a su vez ese inodo está apuntando a los datos).

Resumiendo, que todo lo relacionado con BTRFS va viento en popa. ¿He dicho ya que casi todo esto lo está haciendo un solo hombre, Chris Mason?