Páginas

jueves, 16 de septiembre de 2010

Comenzando...

Quizas la razon por la que no me gustan los blogs sea la misma por la que de pequeño no me gustaba tener un diario secreto, pero lo cierto es que con la cantidad de veces que me he estampado la cabeza desarrollando el sistema de archivos creo que el hecho de que tengamos que mostrar nuestras inquietudes y nuestros miedos en el concurso es una buena idea, asi que aqui esta: el famoso y siempre infravalorado primer post de un blog :-D

Y despues del comentario ironico para romper el hielo, la charla. PirannaFS es un sistema de archivos de ambito general con la idea de ser ampliamente modular, ampliable y flexible y que incorpore todas las novedades que traen los sistemas de ficheros modernos pero desde una perspectiva distinta. Hasta ahora, en el State-of-Art todos los grandes sistemas de archivos modernos como son NTFS, Ext3/4, HFS+, el fallecido WinFS o mi siempre idolatrado ZFS han estado implementando funcionalidades de motores de bases de datos como demuestra el hecho de que cuando se abandono el desarrollo de WinFS se utilizo su codigo para mejorar el motor de Microsoft SQL.

Y dije yo, ¿para que hacer un sistema de archivos que funcione como el motor de una base de datos cuando se puede usar el motor de una base de datos directamente? Llevaba bastante tiempo queriendo probar como funcionaba la libreria FUSE (Filesystem in USErspace) y debido a mis ultimos proyectos con python he estado usando bastante SQLite, asi que cuando llegue al ultimo capitulo del libro de Tanembaum (respecto a la lectura me parezco un poco a Hermione y su "lectura ligera" :-P ) me di cuenta no solo que eran bastante sencillos de implementar sino que ademas habia mucho terreno donde innovar, asi que la inspiracion para empezar a desarrollar PirannaFS fue casi instantanea: desarrollar una prueba de concepto de un sistema de archivos cuya administracion este gestionada enteramente por un motor de base de datos y aprovechar todas sus ventajas, como journaling de datos, poder personalizar las estructuras de las tablas segun se necesite...

Sin embargo despues empece a recordar los comentarios/criticas/quejas/sugerencias/ideas que habia leido al respecto de que con los discos duros externos y los pendrives tan grandes que hay hoy dia un sistema como FAT32 se hace ineficiente, y las alternativas que hay o bien no son practicas para un sistema portatil (NTFS o Ext3 o HFS+ tienen problemas con la portabilidad, y mas importante aun, con los permisos de lectura/escritura que lo unico que hacen en un pendrive es incordiar) o bien estan sujetos a durisimas patentes como es ExFAT, la evolucion de Fat32 a los 64 bits y a los Exabytes que estan por venir, encontrandonos con que no hay ningun sistema de ficheros apto para las necesidades de hoy dia.

Por todo esto, cambie las expectativas de PirannaFS a otras mucho mas ambiciosas: desarrollar un sistema de archivos factor comun y minimalista hasta el absurdo delegando toda la funcionalidad extra a modulos externos (el sistema base ni siquiera tiene soporte para links simbolicos :-) ) permitiendo ser usado alla donde no haga falta mas, pero preparado para poder ser ampliado y personalizado a traves de modulos externos que funcionen alla donde esten habilitados segun las necesidades del usuario: versionado de archivos, logging de actividad, ACLs, checksum de los datos, busqueda por metadatos, soporte de varios volumenes de disco simultaneamente...

Y aunque todavia falte mucho para ello y quizas tenga que cambiar de python a C y embeber el motor de SQLite dentro de la aplicacion, espero que algun dia en lugar de estar la base de datos separada de los datos propiamente dichos llegue a ser autocontenido y pueda llegar a arrancar linux desde el :-D