24 de marzo de 2008

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?

6 comentarios:

  1. A ver si se ponen las pilas los de ext3, porque este hombre viene pisando fuerte :-D

    ResponderEliminar
  2. Interesante, no conocía BTRFS así que gracias por hablar de él.

    Una duda, según la entrada de Jeff Bonwick a la que apuntas, no hay ningún producto en el mercado que provea de RAID-Z:
    "You have to traverse the filesystem metadata to determine the RAID-Z geometry. Note that this would be impossible if the filesystem and the RAID array were separate products, which is why there's nothing like RAID-Z in the storage market today."

    Entonces, suponiendo una implementación de ZFS en Linux completa y correcta, ¿sería posible construir un RAID-Z? ¿o depende de algo más?

    Un saludo y gracias.

    ResponderEliminar
  3. Es cierto en Linux puedes implementar RAIDZ simple y doble sin problemas:

    http://vfernandezg.blogspot.com/2008/09/zfs-on-linux.html

    Un saludo.

    ResponderEliminar
  4. No veo problema alguno con CRFS. Según he leído en los enlaces que pones, no se trata de que esté ligado a BTRFS sino que ofrece ciertas utilidades gracias a usar BTRFS en el servidor. Entiendo que en la medida que en el servidor se pusiese un sistema de ficheros con esas capacidades, el uso de CRFS sería posible. Me parece más bien una cuestión de mínimos: los mínimos han cambiado respecto a NFS (usuarios, grupos, permisos tipo UNIX, parches para ACL, ...).

    Espero que esto sirva de inspiración para la gente de FUSE, en la medida uno pueda hacer montajes sencillos por ssh con este tipo de capacidades en un futuro no demasiado lejano...

    ResponderEliminar
  5. Anónimo7:40 a. m.

    Btrfs will rock.

    ResponderEliminar
  6. Anónimo5:08 p. m.

    rrey:
    ext3 está desfasado hace años. Y ext4 no promete más que un "parche" encima de un sistema ya desfasado.
    Hoy en día, aún sin Btrfs, hay opciones mucho mejores y más modernas para linux: ReiserFS, JFS, XFS...
    Aunque ya se sabe, nuestros amd64 no son más que parches sobre parches sobre parches a un procesador (8088) con bus de datos de 16 bit (aunque el bus externo era de 8) y bus de direcciones de 20...

    ResponderEliminar