Por Jake Edge, traducción de Ángel Ortega. Artículo original: http://lwn.net/Articles/302251/
Uno de los proyectos del núcleo que parece estar atrayendo gran cantidad de interés estos días es el nuevo sistema de ficheros con «copy-on-write», Btrfs. Pese a estar aún algo inmaduro - se planea tener terminado el formato en disco para finales de este año - Btrfs ha alcanzado el punto en el que el principal desarrollador, Chris Mason, quiere empezar a hablar sobre cuándo incorporarlo a la línea principal de desarrollo. Algunos abogan por hacerlo ya, mientras que otros se muestran escépticos acerca de que su inclusión se traduzca en un desarrollo más rápido.
Incorporar Btrfs tendría varias ventajas, pero lo que Mason busca es «más ojos»:
"No obstante, el código está siendo desarrollado muy activamente, y creo que la mejor forma de avanzar desde aquí es meterlo en el núcleo principal (con un aviso enorme sobre el formato en disco) y así atraer más estudios hacia el formato en disco y el código relacionado.
Los desarrolladores de Btrfs nos hemos comprometido a hacer que el FS funcione y a llevarnos bien con la comunidad de desarrolladores del núcleo. Pienso que todo el mundo estará más contento con el resultado final si soy capaz de atraer globos oculares lo antes posible."
Habitualmente, el código no se incluye en el núcleo hasta que está listo, pero se puede argumentar que los sistemas de ficheros, al igual que los controladores de dispositivos, están suficientemente aislados del resto como para que una inclusión temprana ocasione algún daño. Además, se sentó un precedente con la temprana inclusión de ext4, aunque fuera una evolución del sistema de ficheros ext3 existente, mientras que Btrfs es completamente nuevo. Andrew Morton ha estado animando a Mason a meter Btrfs «en linux-next lo antes posible e incorporarlo al 2.6.29». Su razonamiento es el siguiente:
"Lo que pienso es que btrfs probablemente tiene futuro, y que una incorporación temprana aceleraría el desarrollo y ampliaría su plantilla de desarrolladores. Si acaba fallando por cualquier motivo, pues bueno, podemos simplemente borrarlo.
Por varias razones este método no es apropiado como una política general, pero pienso que Linux necesita un nuevo sistema de ficheros local, y btrfs podría serlo, y por tanto merece un tratamiento especial."
Adrian Bunk no está convencido de que una inclusión temporana traiga los beneficios que Morton proclama, señalando a una planificación de desarrollo inicial del ext4 y haciendo notar que el cronograma descrito en aquel mensaje era, quizá, demasiado optimista. «Cuando lo comparas con lo que ocurrió en realidad, de alguna forma desmiente tu argumento de 'aceleración'».
No obstante, Serge Hallyn señala una diferencia entre ext4 y Btrfs:
"Por otra parte, quizá soy yo, pero pineso que hay más interés alrededor de btrfs. Personalmente me muero por el soporte de «snapshots», y no puedo esperar a probar btrfs en mi partición de datos / pruebas (donde no me importa perder datos). Btrfs y nilfs - ¡Sí! ¿Ext4? bah. Eso puede marcar la diferencia."
El cronograma original apuntaba a mediados de 2007 como el objetivo para un sistema de ficheros ext4 estable, pero el proyecto se pasó más o menos un año. Un parche reciente propone renombrar ext4dev a ext4 porque «está llegando a ser suficientemente estable como para quitar el prefijo 'dev'». Algunas dificultades inesperadas llevaron a que el desarrollo de ext4 se retrasara, según Mason describe:
"Ext4 siempre ha tenido que lidiar con el fantasma de ext3. Tanto desde un punto de vista de compatibilidad como por las esperanzas de estabilidad por parte de todo el mundo. Creo que la mayoría de nosotros desestima lo difícil que ha tenido que ser hacer avanzar a ext4."
Muchos parecen pensar que Btrfs es diferente, pero a pesar de todo todavía queda camino por recorrer. Actualmente, no maneja los errores de entrada/salida demasiado bien, y quedarse sin espacio en disco puede ser fatal. Pero está cerca de ser calificado como usable - al menos en lo que a pruebas y rendimiento se refiere. Conseguir que el código entre en el núcleo principal hará que más gente lo eche un vistazo y pruebe los cambios. Mason da un ejemplo de lo que podría ocurrir:
"Por ejemplo, fíjate en los parches que envié a fsdevel la semana pasada. Yo no podría haberlos probado con ext4 tan a menudo si hubiese tenido que andar cazando repositorios externos sólo para conseguir algo consistente con los últimos núcleos de desarrollo. Que Ext4 esté en el núcleo principal me lo ha puesto mucho más fácil."
El cronograma agresivo de Btrfs tiene planificado llegar a la versión 1.0 este año. El objetivo de esa versión es dejar inmutable el formato en disco de forma que los cambios posteriores sean compatibles hacia atrás. Dado que el 2.6.29 será liberado a principio o mediados de 2009, parece bastante posible que Btrfs sea merecedor de ser incluido entonces, lo que significa que realmente no es prematuro empezar a considerarlo ahora.