Páginas

jueves, 4 de noviembre de 2010

Horror, espanto, pavor (2ª parte... y media)

Si antes me quejo de lo malo que es Python-FUSE para depurarlo y para hacer unidades de test, antes me encuentro con otro con el mismo problema :-P

Bindings de FUSE para python hay varios (eso ya lo sabia) y escogí Python-FUSE aparte de por ser el mas famoso y el "oficial" (o al menos es del unico que hay documentación en la pagina de FUSE) porque ya habia paquetes en Ubuntu. Lo que yo no sabia es que otra de las alternativas (fusePy) tenia paquetes dentro de la CheeseShop (si, asi se llamaba hasta hace poco el repositorio de paquetes oficial de Python antes de "profesionalizarse"), y por lo que parece esta alternativa no solo es mas "pythonica" que Python-FUSE sino que ademas es mas completa respecto a funcionalidad de bajo nivel, y para muestra un boton:


>>> from fs.memoryfs import MemoryFS
>>> from fs.expose import fuse
>>> fs = MemoryFS()
>>> mp = fuse.mount(fs,"/mnt/my-memory-fs")
>>> mp.path
'/mnt/my-memory-fs'
>>> mp.unmount()


Si con esto no es mas facil el hacer las unidades de test sin necesidad de hackeos que baje FSM y lo vea. El problema viene entonces de tener que rehacer PirannaFS usando como base estos nuevos bindings o si hacer PirannaFS compatible con los dos, asi que quizas lo mejor sea estudiar previamente si realmente sera rentable o no, y leyendose el codigo no creo que baste. No se, otra alternativa podria ser el hacerme algun otro sistema de archivos (¿otro mas?), pero FullFAT no tiene bindings en Python (aparte de que queria usar la libreria para "entrenarme" para el paso a C++ de PirannaFS) y no he encontrado nada de bindings de Ext3 en Python, aunque sin lugar a dudas estaria interesante el hacerse una implementacion completa de Ext3 en Python (para chulo, yo :-P ). ¿Vosotros que opinais? ¿Reciclaje? ¿Reimplementación? ¿Mirar para otro lado y hacer como que no he visto esto? :-P

Al menos, de regalo me he encuentrado que CUSE, el hermano pequeño y marginado de FUSE para desarrollar drivers de dispositivo en espacio de usuario (el tio que lo desarrolló se dio cuenta que solo hacia falta añadir dos IOCTLs a FUSE para tener soporte para poder escribir drivers genericos fuera del kernel...) y del cual a casi nadie parece importarle (o al menos no he visto ningun proyecto importante o ni siquiera una pagina con documentacion)... ¡¡¡me encuentro con que han desarrollado unos bindings para Python!!! :-D

Quizas empezase PirannaFS porque CaOS (mi propio sistema operativo que llevo diseñando desde que tenia 10 años) se me hacia muy grande, pero parece que todo el universo se esta conspirando en que lo saque adelante... :-)

Horror, espanto, pavor (2ª parte)

Nota mental: plantearme hacer de proyecto para el año que viene o una maquina del tiempo o un replicador de cuerpos o diseñar una droga que permita alterar la percepcion del tiempo sin los efectos secundarios de la cocaina y que pegue mas fuerte por las mañanas que un cutrebull del Lidl... la falta de tiempo es acuciante, y ahora que se acercan los examenes creo que la mejor opcion va a ser dedicarme a la meditacion tibetana, a ver si asi consigo concentrarme...

Quejas varias aparte, pequeño resumen de en lo que he estado perdiendo el tiempo ocupado las ultimas semanas:

Para empezar, como ya puse en mi anterior post he empezado a realizar baterias de test para el sistema de archivos. Por un lado me hacia falta aprender a hacerlas, porque es algo que siempre he estado dejando de lado, y aunque no ha sido pan comido lo cierto es que no ha sido tan dificil como pensaba, pero la razon mas importante para hacerlo era el tema de difundir el proyecto, porque siendo un proyecto tan complejo y "delicado" (nadie quiere poner sus datos en peligro, y bastante ya me esta dando por [autocensurado] el Ext4 en el Ubuntu del trabajo poniendose en modo solo lectura cuando le doy un poco de caña por un error del kernel respecto a los timeout en discos lentos y antiguos... ¬¬) se necesitaba algun metodo para controlar la evolucion del proyecto y sobretodo para evitar regresiones. Y si, tengo que reconocer una cosa: funcionan, y mucho mejor de lo que pensaba. Tuve bastantes problemas a la hora de realizarlo por la forma en que esta diseñado python-fuse (no se si seria mejor arreglarlo o rehacerlo de cero...) pero lo cierto es que consegui que funcionara, y cuando despues de arreglar unos pequeños fallos que me encontre en la implementacion vi esto


[piranna@Tontodelculo:~/Proyectos/FUSE/PirannaFS/src]
> cat ../test/error.log
...............
----------------------------------------------------------------------
Ran 15 tests in 4.176s

OK


realmente se me puso una sonrisa de oreja a oreja :-D

Pero mas interesante que esto fue cuando leyendome las especificaciones del OpenGroup vi algo que me dejo totalmente desconcertado: en readdir especifica que los famosos . y .. solo deben ser mostrados si el sistema de archivos en cuestion tiene referencias explicitas a ellos, cosa que no es el caso (y de hecho siempre me ha parecido una tonteria si ya sabemos tanto cual es el directorio actual como cual es el padre). Sin embargo en todos los ejemplos y documentacion que he visto los ponian explicitamente a mano. ¿Que hacer, saltarse el estandar, o seguirlo fielmente a pesar de que luego al listar el directorio se vea raro? Al final, como no sabia si la lista de correo del concurso podria servir para esto (apenas acababa de comenzar a usarse y esto era una pregunta muy especifica y hasta cierto punto yo entendia que seria cierta ventaja si alguien me ayudaba) asi que pregunte a mis colegas de AlcorconWireless, y como suele suceder en estas cosas mi amigo Dani (que al final le voy a tener que meter en los titulos de credito por toda la ayuda que me esta dando :-P ) dio con la mejor solucion:

mas friki.. activa una opción para verlos o para no verlos.. jajajaaja

Esa es la diferencia entre un ingeniero y uno que presume de serlo teniendo apenas la mitad de los creditos aprobados. Simplemente brillante.

En fin, la cuestion es que aunque apenas tengo tiempo sigo sacando las cosas adelante, solo espero que con el trajin que llevo no termine implosionando por el estress :-P Espero a ver si para el proximo post ya tengo terminados las unidades de test, porque iba a haber hecho una release especial para Halloween y lo cierto al final ha sido que hacia una semana que no encendia el PC de casa... :-P

martes, 19 de octubre de 2010

Horror, espanto, pavor

Acabo de darme cuenta de porque casi nadie hace baterías de test de casi nada, y no es porque no lo enseñan en la universidad... Acabo de hacerme la batería de test de la función ftruncate (es en la que mas modificaciones he hecho ultimamente con las optimizaciones. Ademas, por algun sitio tenia que empezar...) siguiendo las indicaciones de funcionalidad y errores de OpenGroup y me ocupa 254 lineas... y eso que solo he comentado lo que hace cada test, que ahora me toca programarlo :-/ Ahora bien, con la paliza que me voy a pegar, ¿que deberia hacer, acceder a las funciones a bajo nivel, o hacerlo rollo shell script y que ya que me pego la paliza con los test al menos que sirva para que otros no tengan que implementarselos tambien?

Y en plan recursivo... ¿deberia hacer una bateria de test para la bateria de test para testear que la bateria de test testea correctamente? X-D

domingo, 17 de octubre de 2010

[0.2.3] Checksums de Octubre

Casi 20 dias despues... nueva release :-D

Este mes ha sido de aúpa, entre el trabajo y la demostración de este miércoles (que FSM nos coja confesaos...), los estudios (de los cuales todavía no tengo todos los apuntes), los compromisos sociales (aunque algunos han merecido la pena... aunque podrian haberlo merecido mas :-P ) y que los [auto-censurado] checksums se me habian atragantado no he parado quieto, pero bueno, tal y como dijo Mao "una revolución a la vez" al final esta saliendo todo adelante :-D

En primer lugar estaba el tema de los plugins. Los checksums no aportaban simplemente funcionalidad no existente como pasaba con los symlinks sino que trabajaban directamente con los datos, por lo que ya no se podia usar un simple mapeo como antes sino que habia que empezar a desarrollar el sistema de plugins, y a ser posible de una forma un poco mas consistente que como lo habia hecho antes. Por suerte fue facil y ademas el codigo ha quedado bastante limpio, pero tengo la sospecha de que en el futuro voy a tener que hacerle profundos cambios para darle mas potencia y versatilidad (conflictos entre modulos es lo primero que se me viene a la cabeza, luego vereis porque).

Pero el principal problema que tenia con los checksums (y que no identifique hasta hace poco) no estaba relaccionado directamente con ellos, sino que mas bien era un pequeño fallo de diseño (mas bien de falta de planificación) que tuve cuando desarrolle el codigo de escritura y modificación de los archivos (el cual en su momento ya me dio bastante guerra hasta el punto de tener que modificar el diseño de la base de datos tres veces...). Este fallo consistia por un lado que accedia desde distintos puntos del codigo directamente a las funciones DB.Split_Chunks y a LL.Write, con lo que a la hora de generar los eventos para los plugins tendria que generarlos desde multitud de sitios distintos. Sin embargo su funcionalidad era muy parecida y de hecho el codigo era casi el mismo en muchos sitios (como ya indique en mi anterior post entre DB.truncate y DB.Split_Chunks), asi que finalmente he conseguido encarrilar a todo el ganado a través de una nueva función (File.__Split_Chunks) que se encarga efectivamente de llamar a DB.Split_Chunks y de generar el evento correspondiente en caso de que haya producido alguna división.

Al menos todo este follón me ha servido para varias cosas: en primer lugar, una revisión a fondo del código de los archivos, de la base de datos y del acceso a bajo nivel (este al fin es una clase y es instanciada en FileSystem, con lo que ya no abrirá y cerrara el dispositivo en cada llamada. La ventaja es que el acceso es mucho mas rápido, el inconveniente que usara los buffers de archivo del sistema y no escribirá los datos directamente a disco y todavía no estoy usando las transacciones, que es justo una de las razones por las que decidí usar un motor de bases de datos, para aprovechar las que ya tiene... :-/ ). Esta revisión me ha permitido aplicarle muchas mejoras menores y reutilizar mucho código duplicado, con lo que ahora el tamaño y las posibilidades de error son menores, pero sobretodo he quitado "inteligencia" a la base de datos (ahora solo ejecuta sentencias SQL, apenas toma decisiones por si misma aunque lo cierto es que se podría "estupidizar" aun mas) y he eliminado la notificación de eventos desde la base de datos y el acceso a bajo nivel, con lo que por un lado permite mayor control de quien envía realmente los eventos (todo se esta perfilando a que la comunicación entre los plugins va a ser realmente sencilla... :-) ) y también permite mayor portabilidad en el futuro a otros motores de bases de datos o sistemas de almacenamiento o incluso a sacar el código SQL a archivos externos y que los parsee en el arranque en lugar de estar directamente dentro del código Python (esta idea la tengo desde hace tiempo, pero aunque permitiría un mejor mantenimiento al poder tenerlo aislado y que sea mas fácil procesarlo con un editor de texto con coloreado de sintaxis -me encantan :-D - todavía no me he planteado en serio el realizarlo porque consumiría mas memoria y seria un poco mas lento... :-/ )

Ademas todos estos cambios me han hecho replantearme en serio la necesidad de hacer modulos de prueba, por lo que voy a empezar a usar PyUnit, que es el estandar en Python. Nunca he desarrollado ninguno y ademas siempre he sido reaccio a hacerlos (si funciona, ¿para que comprobarlo?) pero un proyecto tan complejo como este lo necesita. Por suerte hace tiempo cuando estaba buscando los codigos de error de los sistemas de archivos tratando de averiguar porque fallaba me encontre con esta pagina que contiene la definición de todas las funciones UNIX con sus parametros, errores y limitaciones, con lo que me vendra de perlas para desarrollar los modulos de test (espero que no me pidan comprar una licencia de POSIX o que Linux Tordvalds me preste la suya... :-D ). Tambien aprovechare a documentar todo el codigo con vistas a liberar publicamente la version 0.3 a ver si se apunta alguien a echarme una mano, y tambien aprovechare a cambiar la filosofia de la API, ya que hasta hace poco (bendito trabajo que tambien lo estoy haciendo en Python y me permite aprender de forma intensiva... :-D ) no entendia correctamente uno de los aspectos mas extraños del lenguaje: en Python no hay metodos o atributos privados, todo es publico. Sin embargo por convenio los atributos y metodos que empiezan con un guión bajo (_) no se muestran en el completado de sintaxis, aunque se sigue podiendo acceder normalmente a ellos. Aparte tambien estan los que empiezan por dos guiones bajos (__) que aqui si el lenguaje los considera como atributos especiales y su firma es distinta, haciendo por tanto que sea mucho mas dificil acceder a ellos. Hasta ahora solo usaba este ultimo metodo para emular los atributos privados, pero realmente era un engorro cuando me encontraba con que queria acceder a algo que habia ocultado demasiado hasta que descubri en que se basaba esta diferencia: la filosofia en Python es la confianza en el programador, por lo tanto no tiene sentido pensar en atributos publicos, protegidos y privados, sino en mostrar (normal), no mostrar (_) y ocultar (__), teniendo en cuenta por ambas partes que si quieres acceder a algun sitio siempre vas a poder pero que necesitas tener buenas razones para ello (por ejemplo, en los debuggers). Despues de tanto tiempo con C++ cuesta acostumbrarse, pero la posibilidad de ver el codigo de los demas para ver que es lo que esta haciendo realmente es de gran ayuda... :-D

Y bueno, ese es el toston de hoy. Espero que cuando este aprendiendo a usar las unidades de test y documentando el codigo no me encuentre con demasiados problemas como hasta ahora, porque entonces esto va a parecer la biblia... :-P Por el momento para mi desgracia acabo de descubrir que ZFS si tiene bloques de tamaño variable (lo que yo creia que era una feature exclusivamente mia... ¬¬) pero por otro lado tambien he descubierto que su algoritmo de compresion tiene una implementación en Python, asi que no hay mal que por bien no venga... :-D
Published with Blogger-droid v1.6.2

domingo, 3 de octubre de 2010

Proyecto Brainstorm

Como habréis podido ver hace días que no escribo por aquí y sin embargo en el svn ha habido muchos cambios... Esto es debido por un lado a que las modificaciones en el core para que acepte el lanzamiento de eventos para los plugins esta siendo mas complicado de lo que parecía debido a que hay que pensar en como aislar correctamente cada una de las partes (hasta ahora no tenia problemas, pero el plugin de checksums funciona a muy bajo nivel y además recibe eventos de distintas partes del código). Sin embargo estos replanteamientos están permitiendo una mayor independencia entre cada una de las partes y además me esta permitiendo el optimizar y documentar código bastante antiguo (en concreto estoy rompiéndome la cabeza para que DB.truncate utilice por debajo a DB.Split_Chunks), así que estoy matando tres pájaros de un tiro :-)

Pero por otro lado también he estado aprovechando el tiempo, y el sistema de plugins ya esta bastante maduro. El sistema me ha quedado bastante escueto y portable, por lo que se podría utilizar en otros sistemas que precisen de un sistema de plugins, pero aunque ya haya otros sistemas de plugins para python (y algunos ya se me han adelantado en la idea de convertirlos en sistema "oficial") lo cierto es que no he visto ninguno que tenga algún mecanismo de control de dependencias entre plugins, y aunque creía que iba a ser mas complicado lo cierto es que al final ha sido casi obvio: al cargar el modulo obtenemos las clases de los plugins y vemos cuales son sus dependencias. Si no están todas disponibles dejamos el plugin pendiente, y si lo están entonces lo cargamos y comprobamos entre los pendientes si para alguno de ellos ha cambiado la situación. Simple, fácil y para toda la familia :-D

Es por esto por lo que todavía no le estoy dando mucha popularidad al sistema ya que quiero tenerlo bien fino antes de abrirlo al publico (sobretodo por el tema de los plugins que se meten muy adentro del funcionamiento del sistema), pero probablemente para la versión 0.3 ya haga un llamamiento publico buscando ideas y colaboradores (y si, prometo que intentare poner al día y en la web cuales son los checkpoints para cada versión...). Sin embargo precisamente por esto he estado actualizando (y limpiando) el diagrama de la estructura de tablas mas acorde a como se esta perfilando el sistema ahora que empiezan a funcionar los plugins (mi idea era implementarlo después de la versión 1.0, pero con motivo del concurso y de la "participación de la comunidad" he tenido que cambiar las fechas para hacerlo mas accesible) y este es el resultado:

(Los colorines son para indicar la dificultad de implementar cada uno de los modulos según cuanto haya que modificar el código: blanco=implementado, verde=directo o casi directo, amarillo=alguna modificación, naranja=reimplementación en parte, rojo=reimplementación de gran parte y turquesa=implementado pero necesita mejoras. Obviamente, con los checksums me equivoque...)

Como podéis ver, arriba a la izquierda tenemos el core, ya implementado. He agrupado lo que correspondería al plugin de directorios y al de archivos porque aunque por el momento no tenga pensado implementarlos como modulos externos, lo cierto es que cada vez me esta tentando mas la idea (¡Mama mama, sin directorios! ¡Mama mama, sin archivos! ¡Mama mama, sin datos! X-D). Luego en el siguiente nivel tenemos los modulos de implementación que como dije anteriormente son dependientes de los elementos del core, y por ultimo tenemos los de valor añadido, en los cuales he puesto el ACL y el log (antes los tenia como de implementación) debido a que no son dependientes directos del core. También tengo aquí a un nuevo vecino en el barrio, xattrs (atributos extendidos), que aunque si es dependiente del core lo cierto es que no depende de sus claves únicas. Además, realmente voy a implementar los atributos extendidos para completar la funcionalidad del sistema de archivos y porque va a ser igual de sencillo que los symlinks (al igual que estos, se podría hacer con un mapeo directo de funciones) ya que a titulo personal, me parece una solución mucho mejor el usar algún tipo de estructura como las tablas id3 y exif, no un simple clave-valor que no da ninguna idea de cuales datos faltan por rellenar (lo admito, estoy obsesionado con los tags de los mp3s en el iTunes hasta el punto de que no solo relleno todos los campos de autor/album/disco/pista/titulo para tenerlos bien organizados sino que le meto dentro a los archivos todas las imágenes del album e incluso la letra de las canciones... :-P). Sin embargo también tengo que reconocer que aunque no son muy usados (al menos son unos completos desconocidos para el usuario medio, y para mi hasta hace poco), realmente pueden ser muy potentes y en un sistema de archivos "tradicional" puede ser usado para implementar un ACL y aumentar el nivel de seguridad, por ejemplo. En cualquier caso, para todo lo que se pueden usar los atributos extendidos un sistema dedicado puede cumplir su tarea mucho mejor, pero las estructuras en los sistemas de archivos tradicionales son demasiado fijas como para añadir este tipo de funcionalidades. Por eso la flexibilidad que ofrecen las bases de datos en estos casos es justo una de las razones que me impulsaron a usar una como base para diseñar el sistema de archivos.

Pero este pequeño by-pass con replanteamiento de puntos de vista incluido también me esta permitiendo el tener tiempo para pensar sobre nuevos modulos, plugins y funciones que añadir al sistema, y parte del merito se lo tengo que dar a mi buena amiga Jennifer, una completa n00b para estas cosas (bastante que la conseguí sacar del lado oscuro y que empezara a usar Linux... :-P) pero que sin embargo su punto de vista como usuario raso me ha sido bastante útil (¡gracias! :-D ).

Una de las ideas que me dio fue el implementar algún sistema de búsqueda avanzada en situaciones limite, del estilo "he buscado la foto del garito aquel en la playa en que estuve desfasando con mis amigas en la que salia guapísima, pero no me acuerdo si es de este año o del anterior y no se si las he borrado o que porque no las encuentro" (nota: aunque no haya dicho nada, casi desde que empecé el proyecto en el diagrama arriba a la derecha hay un modulito muy majo llamado "unlinks"... Si, he pensado en todo, también en otro llamado "purge" que no sale ;-) ). "Además, no quiero que salgan las fotos del tío con el que me enrolle esa noche no sea que entre mi novia en un momento inoportuno cuando este buscando la foto" (a esto ultimo lo llamo yo "ganas de fastidiarme", solo que no con estas palabras...). Al leer esto algunos pensaran que eso es imposible, y otros pensaran que quizás SpotLight o Beagle ya lo hacen (realmente esta idea suya les correspondería mas a unas aplicaciones de alto nivel como ellos que a un sistema de archivos, pero un poco de ayuda por debajo les facilitaría mucho la tarea al igual de lo que podría ocurrir si combinásemos ZFS con TimeMachine... :-) ). Lo cierto es que SpotLight es buenísimo (Beagle nunca lo he usado porque siempre lo desinstalaba ya que mis maquinas con Linux nunca han sido lo suficientemente potentes como para encima tener un proceso accediendo al disco todo el rato...) pero nunca he visto que llegara a un nivel de precisión quirúrgica tan avanzado (quizás lanzandolo desde linea de comandos y procesando una consulta muy elaborada, pero si fuera así de fácil habría un montón de artículos escritos en internet al respecto y lo cierto es que no he oído nada). Yo tengo que ser sincero: es muy complicado, pero no imposible. Aquí el mayor problema depende de la adquisición de los metadatos (día-noche, fechas contextualizadas, reconocimiento de caras...) pero si se tienen y están bien organizados, el problema se reduciría a una simple búsqueda en la base de datos. No diré que lo vaya a implementar... pero si que lo tendré en cuenta para orientar posibles mejoras futuras.

Otras ideas que surgieron entre los dos fueron la eliminación segura de archivos (que ya lo tenia pensado antes pero me gusto ver que no soy el único preocupado :-) ) o la compactación de los archivos (quizás para mas adelante, ya hay suficiente lío con la escritura de los chunks como para encima meter esto). Sin embargo al ver todo lo que esta creciendo el sistema me esta entrando una pequeña duda: ¿y si SQLite no es lo suficientemente potente como para moverlo todo? SQLite es un motor de bases de datos muy optimizado, pero tiene el inconveniente de que cuando se accede a el bloque la base de datos entera, y con tanta funcionalidad añadida a falta de pruebas de rendimiento un sistema que ponga a funcionar muchos modulos podría tener problemas... Una solución bastante practica podría ser el que los modulos en lugar de crear sus tablas en la base de datos principal las creen en bases de datos secundarias, con lo que aparte de aumentar la modularización permitirá el acceder en paralelo a las distintas tablas (sobretodo con equipos multicore como los que se venden hoy día) y además se evitaría el meter "mierda" en la base de datos principal y la desinstalación de modulos seria mas sencilla, sin embargo la adaptación a un sistema autocontenido se complicaría sobremanera. Bien es cierto que todavía queda mucho para entonces, pero siempre es bueno planear tus actos con dos o tres pasos de antelación... :-D Por el momento lo dejo aquí anotado como recordatorio para el futuro ;-)

miércoles, 29 de septiembre de 2010

[0.2.2] El log de Schindler

Hoy debido a la huelga he decidido quedarme en casa, no por apoyarla y no ir a trabajar, sino que ayer me hice una copia de seguridad y he trabajado desde aquí debido al miedo que tenia a los piquetes (no estoy de acuerdo con las reformas, pero tampoco con los sindicatos como la mayoría de la población).

Al final ha sido mas ruido que otra cosa y podría haber ido sin problemas, pero el caso es que como he terminado pronto me he puesto a darle un empujón al sistema de archivos y bueno... hemos alcanzado otro checkpoint :-D Ahora modulo de log esta operativo, he limpiado el modulo de symlinks (ya no hay funciones mapeadas, todas son lanzadas por eventos gracias a louie :-) ) y empieza a discernirse un borrador de como implementar el sistema de plugins. Esto ultimo es debido a que en el modulo de log no tenia manera de tener una referencia para acceder a la base de datos, ya que antes accedía a través del objeto del sistema de archivos (como se puede ver en symlinks, aunque lo voy a cambiar en breve para unificarlo) y ahora al tener el objeto otra estructura perdía toda referencia a ella, y guardarlo en una variable global me decía el bicho que nanai. ¿Como hacerlo? Pues construyendo una clase. Era reacio a hacerlo a pesar de mi gusto por la orientación a objetos porque entonces ya no bastaría con cargar el modulo para tenerlo habilitado, sino que ademas tendría que meterme dentro, leer la clase y crear un objeto, y eso ya es mucho engorro. Por el momento lo he solucionado con la chapuza de crear una instancia del objeto al final del modulo (niños, no miréis :-P ) pero la ventaja de usar orientación a objetos es que mi idea de en un futuro implementar un sistema de dependencias entre plugins (inspirado en APT para mas señas... ;-) ) va a ser mucho mas sencillo :-)

En fin, en cualquier caso el modulo de logs ya esta listo, aunque tendré que diseñar algún método para agrupar los eventos y así poder discernir cuales son validos para loggear y cuales no, porque cuando ya estaba operativo con solo hacer un ls me ha salido todo esto...


[piranna@Tontodelculo:~/Proyectos/FUSE/PirannaFS/test]
> sqlite3 db.sqlite
SQLite version 3.6.22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select * from log;
|__init__|DB|2010-09-29 18:34:31||{'self': , 'db_name': '../test/db.sqlite'}||
|readlink|FileSystem|2010-09-29 18:34:32||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:32||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:32||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }||
|readlink|FileSystem|2010-09-29 18:34:39||{'path': '/nano_link.txt', 'self': }||
sqlite>


Si, efectivamente, FUSE hace muchas llamadas al sistema... ;-)


P.D.: entrada libre de faltas de "hortográfia" ;-) dedicada a Pau y su muy buen consejo :-)

sábado, 25 de septiembre de 2010

[0.2.1] Symlinks, Plugins y cintas de video

Aunque he tardado algun tiempo en actualizar cosas debido a lo saturada que tengo la agenda este año entre el trabajo y la carrera (aunque segun he visto en los blogs de los demas no soy el unico, bien por nosotros :-) ) al fin ha llegado el viernes tarde y para desconectar de una semana demasiado corta en tiempo (se me ha pasado volando sin darme cuenta, con lo que me jode...) y demasiado larga en estress en la que incluso he perdido mi maravilloso Android (snif...) me he puesto a darle un pequeño empujon al proyecto y a falta de uno hay dos: primero, ya tenemos links simbolicos, y segundo, ya tenemos una plataforma seria de plugins, aunque por ironico que parezca no por culpa del codigo para generar los links simbolicos, sino por culpa de la creacion de su tabla.

En primer lugar, los links simbolicos tienen sus propias funciones dentro de FUSE (symlink para crearlos y readlink para parsearlos), los cuales hasta ahora no las habia implementado porque no eran necesarias para el nucleo del sistema de archivos, asi que como primera aproximacion al sistema de plugins decidi mapearlas directamente dentro de la clase, al igual que he hecho con sus equivalentes en la base de datos.

Sin embargo para la creacion de la tabla no podia mapear ninguna funcion sino que tenia que ejecutarse cuando terminara de hacerse la base de datos entera, asi que buscando algun ejemplo de como hacer un sistema de notificacion de eventos en python (podia hacermelo yo y los ejemplos que encontre eran muy parecidos, pero queria ver si ya habia algo bien hecho y probado que poder reutilizar. Al menos esa es una de las ventajas del software libre, que si ya hay algo bien hecho no hay porque duplicar esfuerzos, ¿no?) y entre todo lo que encontre el que mas se parecia a lo que necesitaba para el sistema de plugins fue este codigo. Sin embargo aparte de que no me gustaba mucho como tenia implementado el sistema de carga de plugins (¿un archivo de configuracion? Por favor... con lo comodo y practico que es tener un directorio desde donde cargarlos al igual que se hacia con las extensiones del sistema del MacOS Classic...) tambien hacia referencia a PyDispatcher, el cual tambien hacia referencia a Louie. ¿Cual escoger? Al final como muchas otras veces en que tengo alternativas de codigo y me da igual uno que otro, deje que Ubuntu eligiera por mi para ver cual era el metodo mas estandar, y como Louie era el unico que tenia paquetes dentro de los repositorios oficiales, pues me decante por el :-)

Asi que aunque ha sido por algo completamente accidental, ahora tenemos un sistema de notificacion de eventos bastante avanzado. Puede que sea un problema con vistas a una futura implementacion como sistema de ficheros nativo (mas librerias externas, mas problemas de integracion), pero como apenas todavia estamos en las primeras fases de desarrollo todavia hay tiempo de modificarlo mas adelante si hace falta. De momento en cualquier caso hara falta una plataforma de plugins mas solida que la que tengo actualmente de mapear las funciones directamente, asi que a lo mejor con suerte incluso consigo matar dos pajaros de un tiro y consigo desarrollar un sistema de plugins lo suficientemente bueno como para que me lo incluyan en la libreria estandar de python (y eso si que seria un puntazo... ;-) ).

Proximo paso, aprender un poco mas como funciona Louie y desarrollar el plugin de log :-D

domingo, 19 de septiembre de 2010

Una pequeña idea...

Como puse en mi anterior entrada, PirannaFS empece a hacerlo entre otras razones porque queria experimentar con FUSE. Si, cuando quiero probar una nueva tecnologia no me leo un manual y hago el famoso Hola Mundo, me saco mi propio libro :-P y es por eso por lo que debido a todos los problemas que estoy teniendo para desarrollar PirannaFS y lo escueta, ofuscada y desfasada que es la documentacion que se puede encontrar en la pagina de FUSE por lo que estoy escribiendo mi propio tutorial de desarrollo de sistemas de archivos usando python y FUSE.

Mi idea en un principio era utilizar PirannaFS directamente como codigo de ejemplo del tutorial y es por eso por lo que he intentado que el codigo fuese lo mas claro y limpio posible, pero lo cierto es que el proyecto se ha convertido en algo realmente grande y complejo, aparte de por las optimizaciones que le he hecho para la escritura de los archivos como sobretodo por el usar una base de datos (y eso ya si que no es normal) asi que decidi empezar de cero otro sistema de archivos, este ya con mas complejo de Hola Mundo ;-)

PyRamFs es un sistema de archivos que usa objetos en memoria para guardar los datos: los archivos son strings y los directorios son diccionarios. Mas simple, imposible :-D Lo bueno del caso es que lo he estado escribiendo en orden de importancia a la hora de realizar un sistema de archivos, y es por eso por lo que empece con los archivos antes que con los directorios con lo que hasta ahora es un sistema de archivos de un unico nivel como el de CP/M y similares. Realmente me esta quedando bastante simple y minimalista, en parte por la simpleza del diseño y en parte porque ya no me pilla de nuevas, y es por eso que pense: si este sistema es tan simple porque (por ahora) no tiene subdirectorios... ¿se podran sacar tambien los subdirectorios del nucleo de PirannaFS para que sea aun mas simple e implementarlos como un modulo externo al igual que ha pasado con los links simbolicos?

Asi que nada, me fui al diagrama en el que tengo organizadas las tablas de la base de datos a echar un vistazo :-D

(Lo que esta en el recuadro azul son las tablas del core, las que estan alrededor son modulos "de ampliacion" ya que sus primary keys coinciden con las de las tablas del core y amplian su funcionalidad, y las dos tablas de abajo son de modulos auxiliares en los que su primary key no es dependiente de ningun elemento almacenado en el core)

Como podeis ver, dentro del core estan bastante separadas las tablas relativas a los directorios de las relativas puramente a los archivos, por lo que si no fuera por el nombre y por la fecha de creacion de la tabla links no seria complicado el sacar los directorios fuera y que el core funcione con un unico directorio aunque sin lugar a dudas donde se complicaria mas el tema seria con las consultas de acceso a los datos, que tendria que volver a cambiarlas (¿otra vez a cambiar la estructura de la base de datos? no, por favor...).

Sin embargo, la idea me gusta. No se si sera mejor desarrollarlo tambien como otro modulo externo y que el usuario elija uno u otro, o si ver la posibilidad de sacar los campos de nombre y creacion de la tabla links a una tabla aparte que sea la que se mantuviese dentro de la estructura minima para poder acceder a los archivos, pero en cualquier caso viendo el diagrama me he dado cuenta que aunque no tuviera nombres de archivo tampoco seria mucho problema, ya que si llego a implementar los modulos de metadatos (como el ejemplo que tengo puesto de mp3) se podria acceder directamente a traves de las bibliotecas de musica, fotos o lo que sea puramente a traves de los metadatos y entonces eso si que seria algo revolucionario: un sistema de archivos sin archivos :-P

Ahora bien, en caso de que llegara a implementarlo, ¿como lo hariais vosotros? ¿que el usuario tenga que decidir entre los dos modulos (un solo nivel o sistema jerarquico), o dividir la tabla links y que el mono-nivel este por defecto? ¿la tabla directories tendria algun sentido entonces (esta puesta para forzar luego en las consultas que links.parent_dir sea efectivamente un directorio valido)? ¿lo tiene ahora?

Yo, de momento, ya he alineado dir_entries con files y chunks en el diagrama por si sigo adelante con la idea... ;-)

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