Lo cual significa que ha habido dos versiones que me he saltado aquí desde la última vez que mencione Btrfs aquí. Un ejemplo de constancia, el mio. La novedad de esta última versión es soporte de compresión transparente, soporte de sistemas de archivos "semilla" (puedes tener un sistema de archivos de solo lectura, y todas las modificaciones que se hagan se harán en otro sistema de archivos diferente, sin tocar el inicial), soporte de fallocate() y muchas mejoras menores, aquí se pueden ver los cambios de las versiones anteriores.
Pero dejando de un lado el aspecto técnico, la principal novedad de esta versión es que ha sido incluido en el repositorio oficial de Linus Torvalds y por lo tanto será parte de Linux 2.6.29...otra novedad es que Chris Mason dice que, salvo fallos gravísimos, no están planeados más cambios en el formato de disco.
En otras palabras: Está empezando a madurar.
Francamente, es muy sorprendente lo rápido que ha evolucionado. Fue anunciado al mundo como una cosa bastante incompleta con 10.500 líneas de código en Junio del 2007. Año y medio despues, tiene 32.634 lineas de código (134 más y hubieran sido exactamente 2^15), y ya es casi totalmente funcional en lo que a equivalencia con Ext4 y demás sistemas de archivos tradicionales se refiere. El plan de desarrollo restante trata de características propias de btrfs/zfs relacionadas con snapshots, subvolúmenes...pero los aspectos básicos de leer, escribir, mmap, directorios, xattrs, etc, están completos. Si fuera estable tal y como está, se podrían ignorar las carencias "excentricas" y usarlo como sustituto de Ext4. Por comparar, Ext4 fue anunciado un año antes, en Junio de 2006, y muchas de sus características ya estaban disponibles previamente como extensiones de Ext3 (de hecho, la discusión sobre crear un Ext4 al margen de Ext3 surgió al solicitar la inclusión de uno de esos parches para la próxima versión estable de Linux de entonces). Por supuesto, btrfs es aun muy inestable, pero aun así ha evolucionado increiblemente rápido en mi opinión...
La carencia fundamental de Btrfs en estos momentos es la gestión de -ENOSPC, es decir, no es capaz de detectar correctamente cuando el sistema de archivos está lleno y no caben más datos. Es tan solo un problema del asignador de bloques, pero es complicado de solucionar en estos sistemas de archivos Copy-On-Write: Como cada vez que se modifica un archivo se hace una copia con los datos nuevos en un sitio vacío del disco, y esa copia se hace mediante delayed allocation, cuando el disco está lleno hay que saber de antemano si esa copia nueva va a tener espacio para poder hacerse. Anticipar esas situaciones es la única falta notable de la que adolece btrfs, y es en la que se están centrando en solucionar.
Curiosamente, y al margen de lo que le falte a btrfs, hasta puede darse una situación ligeramente paradójica: Si el disco duro está lleno pero tu no estás planteandote crear un archivo nuevo sino modificar un solo carácter de uno ya existente, un sistema de archivos tradicional en principio te lo permitiría sin problemas, pues a pesar de no haber espacio libre se reescribe el espacio ya utilizado, pero en un sistema de archivos COW se necesita explicitamente espacio para poder escribir el archivo nuevo (o al menos, un pequeño extent que direccione la parte del archivo modificada, más una copia de los metadatos que apuntan a los extents)
Volviendo a Btrfs, una vez solucionado lo de -ENOSPC y solucionados otros pocos puntos del plan de desarrollo, podrá lanzarse finalmente la versión 1.0.
Pues como esto siga así, parece que ext4 no va a ser tan famoso ni tan necesitado :-O
ResponderEliminarEn fin, siento mucha curiosidad por la solución que usarán para el problema.
Yo espero que esto siga así ya que creo que es la evolución lógica de los sistemas de archivos. De hecho me acuerdo cuando salió el BeOS con su BFS y con los atributos extendidos, journaling y demás que fundía a cualquier otro FS de la época. Lástima que desapareciera pero iba por el buen camino.
ResponderEliminarDe todas formas, tengo una pregunta: sé que BtrFS soportará atributos extendidos (xattrs) pero ¿serán del mismo tipo que los del BeOS? Es decir, ¿serán atributos arbitrarios nombre/valor?
Por ejemplo, en BeOS los correos electrónicos se guardaban como archivos. El contenido del archivo era el contenido del correo electrónico mientras que los campos del correo (para, de, cc, bcc, etc.) eran atributos del sistema de archivos. ¿Soportará esto mismo BtrFS? Siento poner la preguntita aquí pero no lo he visto por ningún lado. Gracias.
Diego: Son atributos extendidos UNIX, tradicionales, no como los de BeOS
ResponderEliminarte doy gracias por tu blog, aprendo mucho sobre cosas que no encuentro informacion clara y en español.
ResponderEliminarHola otra vez. He estado leyendo información (no mucha) sobre BtrFS y creo que sí tiene atributos extendidos. Lo único es que no los guarda en el i-node como otros sistemas de archivos, pero sí los tiene.
ResponderEliminarLos atributos extendidos en el mundo Linux aparecieron en XFS (aunque todos sabemos que BeOS los tuvo primero ;)) y no son más que pares nombre/valor arbitrarios para cada archivo.
En Linux hay varios sistemas de archivos que los soportan (entre ellos XFS, ext3, ext4,...) y para acceder a ellos se usa el comando 'attr' que viene del mundo de XFS.
Ahora la cuestión es que se haga un uso intensivo de los mismos como te comentaba en el comentario anterior (que los correos tengan sus atributos en el sistema de archivos, que los MP3 tengan su ID3 en el sistema de archivos, que los documentos tengan su título, autor, etc. en el sistema de archivos, etc.).