Los orígenes reales de Btrfs

En la entrada anterior alababa la rápida evolución de Btrfs, habiendo sido presentado en público como algo aun muy incompleto y con 10.500 líneas de código en Junio del 2007. Lo que no me había dado cuenta es que Chris Mason, su autor y principal desarrollador, ha conservado en su repositorio toda la historia del desarrollo desde literalmente el día 1 de la vida del proyecto.

De modo que al ser incluido en el repositorio de Linus, lo que aparece en log de commits no es un gran único commit de 1MB y pico que dice "Esto es Btrfs", sino toda la lista de cientos de commits que ha tenido el proyecto desde sus inicios, antes de que fuera anunciado al gran público. Además, Git conserva la fecha de creación de los commits (es decir, que si un commit fue creado por un programador en su repositorio local tal día de 2006, aunque se incluya posteriormente en otro repositorio la fecha de creación del commit sigue siendo la del 2006), lo cual permite echar un ojo a la fecha real de creación de Btrfs y la evolución de un proyecto como este a través del tiempo. En exclusiva para D'Oh, un pequeño viaje en el tiempo a los orígenes de Btrfs, una mirada rápida a la evolución de un sistema de archivos desde cero hasta que empieza a ser usable

El primer commit se hizo el 26 de Enero de 2007. Eso significa desde ese día hasta hoy han pasado casi exactamente dos años. El código de entonces no era un sistema de archivos, ni tan siquiera era algo que se ejecutaba en el kernel: Era un simple programa de 810 líneas, ejecutado en espacio de usuario, con su main() de toda la vida: ctree.c, una implementación de un B-tree al que se añaden 10 millones de nodos, despues se hacen unas búsquedas y despues se eliminan los nodos. Todo ello en memoria, sin tocar el disco duro para nada. Un ejercicio algorítmico que en principio podría estar destinado a cualquier cosa que necesite usar B-trees.

Exactamente una semana despues, el 2 de Febrero, se añade la capacidad de escribir el B-tree a un archivo, junto a una copia de la implementación del radix-tree del kernel (lib/radix-tree.{c,h}), utilizada en el caché de páginas, que en btrfs se compila, mediante una serie de "hacks", en espacio de usuario, y con el que aparentemente se intenta imitar una gestión de memoria básica, o al menos de las interfaces del kernel que la implementan.

El 20 de Febrero añade lo que parece ser un soporte preliminar de extents. Poco despues añade un mkfs. Posterirmente, algunos programas para ayudar a depurar el código.

El 2 de Marzo añade lo que parece ser el inicio del sistema de Copy-On-Write. El 13, se añade la base que permitirá el sistema de snapshots.

El 15 de Marzo añade el soporte de diferentes tipos de items, y el soporte inicial del tipo de item "directorio" (pero sin una implementación real de directorios), y ese mismo día añade el item "inodo" (pero sin una implementación real de inodos). Esta es una característica que comparte con ZFS y, supongo, con todos los sistemas de archivos basados en Copy-On-Write: En el nivel más profundo del sistema de archivos no existen archivos ni directorios ni metadatos ni inodos ni nada, todo son "objetos" genéricos que se distinguen en el exterior con un "identificador de objeto", identificador que es utilizado como parámetro para ordenarlos en el B-tree. A ese nivel es al que se implementa el mecanismo COW, la gestión de snapshots, de volúmenes, duplicación de datos, etc; gestionando siempre "objetos" abstractos. Despues, cada objeto puede ser de diferentes tipos: un inodo, un directorio, un extent, un bloque con checksums...o cualquier otra cosa. Por lo tanto, el sistema de archivos en si en realidad se implementa encima de esta "capa de gestión de objetos".

(Hasta ahora, todo esto sigue siendo un programa que se ejecuta en espacio de usuario, nada de kernel...como es natural, a medida que se van añadiendo estas cosas van surgiendo tambien cada vez más commits arreglando fallos, o añadiendo cosas menores)

El día 16 de Marzo se añade el principio del sistema de transacciones, el 20 se añade el tipo de item "extent" y "inode map"

El día 21 de Marzo se añade, por fin, el soporte para montar btrfs en el kernel: No llega a dos meses desde la creación de aquel programita simple, ctree.c. Al mismo tiempo que se añade ese soporte, se eliminan miles de líneas de código que se habían copiado del kernel para intentar imitar sus interfaces (radix-tree, etc).

El día siguiente, 22, se añade soporte de readdir() (o sea, de directorios). Poco a poco se van añadiendo las funciones necesarias que necesita el VFS para que un sistema de archivos funcione: El 23 se añade btrfs_create (crear nuevo inodo), btrfs_sync_fs (soporte de sync()), el 25 se añade soporte de la función del VFS unlink y otra llamada "delete_inode", el 26 se añade mkdir, y tambien se añade el primer soporte para escribir y leer archivos. Truncate y rmdir el 27...como se puede comprobar, el sistema de archivos es en realidad una implementación más o menos "sencilla" de las funciones del VFS sobre el "motor de gestión de objetos genéricos".

El 28 de Marzo se añade soporte de checksums para los metadatos, el 29 soporte para comprobarlos. El 4 de Abril, soporte para que los archivos de tamaño menor que un bloque sean incluidos dentro del B-Tree (algo que btrfs hace para que el acceso a archivos pequeños sea veloz). El 6 de Abril, soporte inicial para varios volúmenes, el 10 soporte mejorado de snapshots y soporte de subvolúmenes, el 11 soporte de múltiples dispositivos...con el tiempo se van añadiendo el resto de las cosas básicas que faltan: soporte de enlaces simbólicos y enlaces duros, archivos "sparse"...todo transcurre más o menos despacio hasta el día 12 de Junio, día en el que se añade la licencia GPLv2 a todos los archivos y se anuncia su existencia en público. El resto es historia conocida.

Es interesante ver como un programa de 810 líneas puede convertirse en un sistema de archivos...