Otra añadido de nuestro programa es la comprobación si ya existe un proceso que se este ejecutando, es decir, que ejecutemos nuestro programa o bien manualmente o bien como tarea programada, y antes de que este termine su ejecución, intentemos ejecutarlo de nuevo.
Para ello lo que hacemos desde nuestro script awk es comprobar si existe un fichero temporal, en caso de que no exista lo creamos y hasta no terminar nuestra ejecución no lo eliminaremos, al estar creado este fichero, en caso de ejecutar de nuevo nuestro programa, este detectará que ya existe ese fichero y que por tanto el programa esta en ejecución para al instante cerrarse, y no entorpecer ni machacar la ejecución anterior.
Para ellos nos ayudamos de las instrucciones BEGIN y END de awk.
jueves, 5 de noviembre de 2009
Politicas personalizadas
Hasta ahora estabamos trabajando y haciendo busquedas simples, o bien por extension o bien por tamaño, pero eran unas politicas muy rigidas, por eso desde el último post, aproximadamente unas 3 semanas nos hemos dedicado a crear un script awk que permita leer un fichero de configuración en el cual las politicas del usuarios sean lo mas flexibles y configurables posibles.
Trabajamos con 5 posibles filtros de politica, que son:
- Tamaño de fichero.
- Ruta de fichero.
- Fecha último acceso.
- Extensión.
- Caching por partes.
A partir de estas 5 hemos creado sus 5 políticas simples, es decir que filtre por tamaño de fichero, por ruta de fichero, etc, y luego combinatoria de dos y 3 de ellas en cualquier tipo de orden, unos ejemplos:
- Tamaño fichero, extensión, ruta de fichero.
- Ruta de fichero y extensión.
- Extensión, ruta de fichero y tamaño de fichero
...
Dentro de esto cabe destacar que tenemos una expresión regular para cada tipo diferente de política, y que son aproximadamente unas 80 o 90, dentro del script awk también tenemos ciertas funciones que nos parsean los datos de la forma que nos conviene y que llaman al nuestro "charging" script con los parámetros necesarios, y que sera el que se encargará de hacer las búsquedas correctas y su posterior caching, estas funciónes estan agrupadas, es decir, que existirá una sola función para la política "extensión y ruta" y "ruta y extensión"
Por otro lado también hemos tenido que adaptar nuestro "charging script" a estas modificaciones, ya que nuestra forma de trabajar ha cambiado de forma considerable, principalmente respecto a la función de búsqueda de ficheros acorde con la política. Hemos conseguido hacer tan solo un par de llamadas al comando find en vez de hacer una llamada por cada tipo de politica, cosa que nos produciría también alrededor de 80 o 90 llamadas al comando find, y esto lo hemos resuelto comprobando a través de un identificador de política el tipo de política y haciendo que los parametros que forman parte del comando fueran variables, a parte de las variables valores que necesitamos buscar.
Un ejemplo seria que al hacer una búsqueda por tamaño nuestro comando seria algo como find -size -"tamaño_introducido".
Pero lo que hacemos es que -size sea una variable $size, y que dependiendo el identificador de política su valor sea "-size" o nulo "".
Trabajamos con 5 posibles filtros de politica, que son:
- Tamaño de fichero.
- Ruta de fichero.
- Fecha último acceso.
- Extensión.
- Caching por partes.
A partir de estas 5 hemos creado sus 5 políticas simples, es decir que filtre por tamaño de fichero, por ruta de fichero, etc, y luego combinatoria de dos y 3 de ellas en cualquier tipo de orden, unos ejemplos:
- Tamaño fichero, extensión, ruta de fichero.
- Ruta de fichero y extensión.
- Extensión, ruta de fichero y tamaño de fichero
...
Dentro de esto cabe destacar que tenemos una expresión regular para cada tipo diferente de política, y que son aproximadamente unas 80 o 90, dentro del script awk también tenemos ciertas funciones que nos parsean los datos de la forma que nos conviene y que llaman al nuestro "charging" script con los parámetros necesarios, y que sera el que se encargará de hacer las búsquedas correctas y su posterior caching, estas funciónes estan agrupadas, es decir, que existirá una sola función para la política "extensión y ruta" y "ruta y extensión"
Por otro lado también hemos tenido que adaptar nuestro "charging script" a estas modificaciones, ya que nuestra forma de trabajar ha cambiado de forma considerable, principalmente respecto a la función de búsqueda de ficheros acorde con la política. Hemos conseguido hacer tan solo un par de llamadas al comando find en vez de hacer una llamada por cada tipo de politica, cosa que nos produciría también alrededor de 80 o 90 llamadas al comando find, y esto lo hemos resuelto comprobando a través de un identificador de política el tipo de política y haciendo que los parametros que forman parte del comando fueran variables, a parte de las variables valores que necesitamos buscar.
Un ejemplo seria que al hacer una búsqueda por tamaño nuestro comando seria algo como find -size -"tamaño_introducido".
Pero lo que hacemos es que -size sea una variable $size, y que dependiendo el identificador de política su valor sea "-size" o nulo "".
sábado, 10 de octubre de 2009
Creando un log
Debido a que nuestro shell script "charging" se ejecuta al ser llamado por nuestro awk "lee_conf.awk", este será ejecutado y cerrado tantas veces como políticas correctas existan en el fichero de configuración. Esto supone un problema, ya que deberemos guardar datos de ejecuciones anteriores, para las nuevas ejecuciones de nuestro shell script. Actualmente el dato que necesitamos guardar es el espacio libre en cache después de cachear los diferentes archivos, una forma guardar este valor es hacerlo en un fichero. Ya que tenemos que generar este fichero de texto con este dato, es una buena opción aprovecharlo para hacer un log de la ejecución de nuestro programa, así que a parte de escribir y leer datos en él para su posterior uso, introduciremos datos que resultarán útiles de cara al usuario final.
Los datos que inicialmente hemos decidido introducir son:
Espacio libre inicial en cache (Lo usaremos en nuestro script).
Número de política aplicada.
Ficheros cacheados en cada politica.
Total tamaño de ficheros cacheados para cada política.
Espacio libre en cache después de cachear todos los ficheros de todas las políticas aplicadas.
Los datos que inicialmente hemos decidido introducir son:
Espacio libre inicial en cache (Lo usaremos en nuestro script).
Número de política aplicada.
Ficheros cacheados en cada politica.
Total tamaño de ficheros cacheados para cada política.
Espacio libre en cache después de cachear todos los ficheros de todas las políticas aplicadas.
Añadiendo Loglevel
Hemos añadido a nuestro shell script "charging" una variable llamado loglevel. Esta variable podrá tener valores del 1 al 4, donde 1 representará un bajo nivel de loglevel, y el 4 el mas alto nivel de loglevel.
El loglevel nos servirá para especificar el nivel de salidas por pantalla queremos en nuestro programa, es decir especificando un 4, en la salida por pantalla de nuestro programa mostrará todos los mensajes del programa y que esta haciendo en todo momento, en cambio si especificamos un 1, nuestro programa mostrará el mínimo de mensajes por pantalla mientras se ejecute, y solo mostrará los eventos mas importantes, como cuando se haya ocupado el tamaño máximo de cache y no se pueda seguir cacheando. Para realizar esto hemos añadido condicionales a cada uno de los "printf" y "echo" que salian por pantalla, y dependiendo el grado de importancia que creemos que tienen se ejecutarán si su loglevel cumple la condición de ser igual o mas grande que el loglevel especificado en la variable inicial.
El loglevel nos servirá para especificar el nivel de salidas por pantalla queremos en nuestro programa, es decir especificando un 4, en la salida por pantalla de nuestro programa mostrará todos los mensajes del programa y que esta haciendo en todo momento, en cambio si especificamos un 1, nuestro programa mostrará el mínimo de mensajes por pantalla mientras se ejecute, y solo mostrará los eventos mas importantes, como cuando se haya ocupado el tamaño máximo de cache y no se pueda seguir cacheando. Para realizar esto hemos añadido condicionales a cada uno de los "printf" y "echo" que salian por pantalla, y dependiendo el grado de importancia que creemos que tienen se ejecutarán si su loglevel cumple la condición de ser igual o mas grande que el loglevel especificado en la variable inicial.
Fallo en crontab
Tal y como comentábamos en el anterior post, la tarea crontab no se ejecutaba de forma correcta, después de hacer diferentes búsquedas, comprobar variables de entorno, etc, creamos un log con la ejecucion de la tarea desde crontab, y nos muestra donde estaba nuestro error, la instrucción que llama a nuestro shell script dentro del código de awk no tenia el path especificado, y no encontraba el fichero, con esto solucionado la tarea se ejecuta correctamente.
Ahora nos faltará solucionar otro problema, en caso que el usuario desee introducir algún asterisco en alguno de los cinco parámetros del momento de ejecución de la tarea, nuestro script no entiende el asterisco como un literal, sino como una expresión regular, una posible solución seria comprobar si los parámetros son asteriscos y modificarlos por rangos 0-59, etc.
Aparcamos este problema de momento, ya que creemos que esa solución deberia funcionar, y lo retomaremos en su momento.
Ahora nos faltará solucionar otro problema, en caso que el usuario desee introducir algún asterisco en alguno de los cinco parámetros del momento de ejecución de la tarea, nuestro script no entiende el asterisco como un literal, sino como una expresión regular, una posible solución seria comprobar si los parámetros son asteriscos y modificarlos por rangos 0-59, etc.
Aparcamos este problema de momento, ya que creemos que esa solución deberia funcionar, y lo retomaremos en su momento.
martes, 6 de octubre de 2009
Modificaciones en fichero de configuración(3) Asignando periocidad a crontab
También vamos a modificar nuestro fichero de configuración para que el usuario pueda asignar la tarea de ejecutar nuestro programa con la periocidad que el elija.
Utilizamos la misma nomenclatura que crontab.
crontab=* * * * *
Lo leemos con nuestro fichero lee_conf.awk y asignamos a las variables correspondientes.
Actualmente no tenemos esta parte funcionando correctamente, ya que tenemos un problema a la hora de ejecutar el programa awk con crontab, estamos consultando en los foros en busca del posible problema y solución.
Una vez solucionado nuestro programa realizará correctamente la tarea programada, y solo nos faltará depurar un poco mas nuestro fichero de configuración y el programa para su lectura.
Utilizamos la misma nomenclatura que crontab.
crontab=* * * * *
Lo leemos con nuestro fichero lee_conf.awk y asignamos a las variables correspondientes.
Actualmente no tenemos esta parte funcionando correctamente, ya que tenemos un problema a la hora de ejecutar el programa awk con crontab, estamos consultando en los foros en busca del posible problema y solución.
Una vez solucionado nuestro programa realizará correctamente la tarea programada, y solo nos faltará depurar un poco mas nuestro fichero de configuración y el programa para su lectura.
Modificaciones en fichero de configuración(2) Asignado tamaño de la cache
De nuevo vamos a realizar modificaciones en nuestro fichero de configuración, esta vez el usuario podrá especificar en tal fichero si desea asignar un tamaño fijo de cache en vez de usar el espacio libre en disco.
Encontraremos una entrada del estilo: cache_size=1000M
El usuario debera especificar un número y una unidad de tamaño, nuestro programa de lectura de configuración encontrará esta entrada y trabajara con ella para enviar los datos necesarios a nuestro script "charging" que será el que se dedique a realizar todas las acciones necesarias para el caching.
Debido a estas modificaciones, hemos tenido que adecuar nuestro programa de caching "charging" para que contemplará la comentada doble posibilidad, que el tamaño de la cache fuera la asignada por el usuario o que sea el espacio en libre en disco. Nuestro script comprobará si el fichero de lectura de configuración le pasa las variables correspondientes al tamaño de la cache, en caso de que no se pasen trabajará con el tamaño libre en disco
Encontraremos una entrada del estilo: cache_size=1000M
El usuario debera especificar un número y una unidad de tamaño, nuestro programa de lectura de configuración encontrará esta entrada y trabajara con ella para enviar los datos necesarios a nuestro script "charging" que será el que se dedique a realizar todas las acciones necesarias para el caching.
Debido a estas modificaciones, hemos tenido que adecuar nuestro programa de caching "charging" para que contemplará la comentada doble posibilidad, que el tamaño de la cache fuera la asignada por el usuario o que sea el espacio en libre en disco. Nuestro script comprobará si el fichero de lectura de configuración le pasa las variables correspondientes al tamaño de la cache, en caso de que no se pasen trabajará con el tamaño libre en disco
lunes, 28 de septiembre de 2009
Modificaciones en fichero de configuración
Hemos realizado ciertas modificaciones en nuestro fichero de configuración, concretamente permitimos que el tamaño asignado por el usuario a la política sea un numero infinito de dígitos. Anteriormente tan solo permitiamos una serie de 3 dígitos, con la expresión regular [0-9][0-9][0-9], lo hemos modificado a [0-9]*, que tal y como hemos comentado nos permitirá introducir un número infinito de dígitos.
Debido a esto también necesitamos modificar como se guarda este valor en nuestro array, ya que anteriormente utilizabamos la instrucción substring, que nos devolvia una subcadena con los tres primeros valores de la variable: 010, 346, etc.
Al ya no ser un valor fijo de 3 dígitos necesitamos utilizar la instrucción "match" que nos devolverá la posición del primer caracter que coincida con nuestra expresión regular, en este caso usaremos algo parecido a esto:
_index=match($mystring,/[\%|M|K|G]/)
Esto guardará en nuestra variable "_index" la posición en la que se cumple la expresión regular, con esto podremos realizar la asignacion de subcadenas a nuestro array, para poder trabajar con los datos.
Debido a esto también necesitamos modificar como se guarda este valor en nuestro array, ya que anteriormente utilizabamos la instrucción substring, que nos devolvia una subcadena con los tres primeros valores de la variable: 010, 346, etc.
Al ya no ser un valor fijo de 3 dígitos necesitamos utilizar la instrucción "match" que nos devolverá la posición del primer caracter que coincida con nuestra expresión regular, en este caso usaremos algo parecido a esto:
_index=match($mystring,/[\%|M|K|G]/)
Esto guardará en nuestra variable "_index" la posición en la que se cumple la expresión regular, con esto podremos realizar la asignacion de subcadenas a nuestro array, para poder trabajar con los datos.
Ejecución shell script desde awk
Tal como comentabamos en el anterior post, debíamos encontrar una forma de ejecutar nuestro shell script desde awk, esta forma es mediante la instrucción "system". Describimos el funcionamiento de esta instrucción con un ejemplo:
system("sh myscript " var1 " texto2 " var3 " " var4)
Nuestro comando de shell "sh myscript" debe ir entrecomillado, ya que es el comando shell que queremos ejecutar, a este le pasaremos ciertos parámetros, tanto cadenas como variables que podrán ser cadenas, números o cualquier otro tipo de datos. Las variables no deberán ir entrecomilladas y tan solo tendremos que escribir el nombre de la variable sin simbolos tipo "$" antes de ellas, el resto de parámetros que pasemos deberán ir entrecomillados. También importante que deberemos tener en cuenta los espacios entre los parámetros, por ello vemos que hay espacios en "sh myscript ", " texto2 ", y que hemos escrito " " para generar un espacio entre las variables var3 y var4.
Una vez que ya hemos descubierto como ejecutar nuestro shell script desde awk, hemos realizado el algoritmo que procesa tal ejecución con los parámetros correspondientes para cada política.
system("sh myscript " var1 " texto2 " var3 " " var4)
Nuestro comando de shell "sh myscript" debe ir entrecomillado, ya que es el comando shell que queremos ejecutar, a este le pasaremos ciertos parámetros, tanto cadenas como variables que podrán ser cadenas, números o cualquier otro tipo de datos. Las variables no deberán ir entrecomilladas y tan solo tendremos que escribir el nombre de la variable sin simbolos tipo "$" antes de ellas, el resto de parámetros que pasemos deberán ir entrecomillados. También importante que deberemos tener en cuenta los espacios entre los parámetros, por ello vemos que hay espacios en "sh myscript ", " texto2 ", y que hemos escrito " " para generar un espacio entre las variables var3 y var4.
Una vez que ya hemos descubierto como ejecutar nuestro shell script desde awk, hemos realizado el algoritmo que procesa tal ejecución con los parámetros correspondientes para cada política.
domingo, 27 de septiembre de 2009
Modificando lectura fichero de configuración
Hicimos una primera versión de como leer nuestro fichero de configuración (file.conf) con awk, y la idea inicial era leer cada politica, y pasar esos datos a nuestro shell script, ya que desde awk el propio cuerpo del programa nos realiza una interación, es decir leeriamos la primera política y llamaríamos a nuestro shell script pasándole los datos de esa política, cuando terminase de ejecutar el shell script volveria a awk y este le volveria a pasar una nueva politica, y así hasta el fin de políticas.
Pero la lógica informática que se ha desarrollado durante los últimos años consiste en completar la lectura del fichero de configuración, antes de ejecutar cualquier programa con estos datos, esto tiene sentido en cualquier caso que nuestro fichero de configuración no sea del todo correcto, ya que estaríamos ejerciendo un trabajo inneceseario y tal vez erroneo, de ahí nuestra modificación. Los cambios que hemos realizado procuran que en el cuerpo de awk donde se realiza una iteración automàtica, sirva para almacenar los datos en un array, con estos datos, al final de nuestro programa awk, generamos un bucle anidado que ejecutará tantas veces como políticas existan nuestro shell script y le pasará a este los datos necesarios para su ejecución.
Tras este cambio, solo nos falta encontrar el comando que ejecute nuestro shell script desde awk.
Pero la lógica informática que se ha desarrollado durante los últimos años consiste en completar la lectura del fichero de configuración, antes de ejecutar cualquier programa con estos datos, esto tiene sentido en cualquier caso que nuestro fichero de configuración no sea del todo correcto, ya que estaríamos ejerciendo un trabajo inneceseario y tal vez erroneo, de ahí nuestra modificación. Los cambios que hemos realizado procuran que en el cuerpo de awk donde se realiza una iteración automàtica, sirva para almacenar los datos en un array, con estos datos, al final de nuestro programa awk, generamos un bucle anidado que ejecutará tantas veces como políticas existan nuestro shell script y le pasará a este los datos necesarios para su ejecución.
Tras este cambio, solo nos falta encontrar el comando que ejecute nuestro shell script desde awk.
sábado, 26 de septiembre de 2009
Agilizando la ejecución del código
Nos interesa modificar nuestro actual código para que se compruebe fichero a fichero (de cada política) si excede el tamaño que queremos utilizar de la caché.
Tenemos dos posibles soluciones, adecuar parte de nuestro código actual, o hacer unos cambios mas significativos, presentamos ambos pseudocódigos posibles y los analizamos.
Posibilidad 1:
para cada fichero
calcula tamaño archivo
fin_para
para cada fichero
si total < espacio_libre
cachear todos los archivos
sino
si total_archivos+nuevo_archivo < espacio_libre
cachear archivo
sino
salir
fin_si
fin_si
fin_para
Posibilidad 2:
para cada fichero
si total+fichero < espacio_libre
cachear archivo
sino
salir
fin_si
fin_para
Podemos ver que la posibilidad 1 va a tener un tiempo de ejecución de n, donde n^2 serà la entrada de datos, en cambio la posibilidad 2 va a tener un tiempo de ejecución de n.
A parte realizamos pruebas de tiempo en ambos scripts, tanto en los casos en los que "tamaño total de todos los ficheros < espacio libre", como en los casos de "tamaño total de todos los ficheros > espacio libre", y en ambos casos comprobamos que el tiempo de ejeución con la posibilidad 2 es sensiblemente inferior al de la posibilidad 1
Tenemos dos posibles soluciones, adecuar parte de nuestro código actual, o hacer unos cambios mas significativos, presentamos ambos pseudocódigos posibles y los analizamos.
Posibilidad 1:
para cada fichero
calcula tamaño archivo
fin_para
para cada fichero
si total < espacio_libre
cachear todos los archivos
sino
si total_archivos+nuevo_archivo < espacio_libre
cachear archivo
sino
salir
fin_si
fin_si
fin_para
Posibilidad 2:
para cada fichero
si total+fichero < espacio_libre
cachear archivo
sino
salir
fin_si
fin_para
Podemos ver que la posibilidad 1 va a tener un tiempo de ejecución de n, donde n^2 serà la entrada de datos, en cambio la posibilidad 2 va a tener un tiempo de ejecución de n.
A parte realizamos pruebas de tiempo en ambos scripts, tanto en los casos en los que "tamaño total de todos los ficheros < espacio libre", como en los casos de "tamaño total de todos los ficheros > espacio libre", y en ambos casos comprobamos que el tiempo de ejeución con la posibilidad 2 es sensiblemente inferior al de la posibilidad 1
domingo, 13 de septiembre de 2009
Programando tarea con crontab
Esta tarea corresponde a una fecha anterior a la creación del post de (creando el fichero de configuración).
Comentar que estuvimos alrededor de dos días haciendo pruebas para conseguir lanzar un script de forma programada desde unix, programandolo para que se ejecutará cada minuto, en el momento en que decidamos cada cuanto se tiene que ejecutar esta tarea se modificarán los parámetros pertinentes del script que crea una tarea programada.
Comentar que estuvimos alrededor de dos días haciendo pruebas para conseguir lanzar un script de forma programada desde unix, programandolo para que se ejecutará cada minuto, en el momento en que decidamos cada cuanto se tiene que ejecutar esta tarea se modificarán los parámetros pertinentes del script que crea una tarea programada.
leyendo fichero .conf(2)
Respecto al problema comentado en el anterior post, creo que una forma de solucionarlo es con un array, guardaré todas las politicas en un array y desglosare cada una de mis politicas de una forma facil y rapida en mi array, para que el posterior trabajo sobre los datos guardados en mi array sea más rápido. Por otro lado intentando solucionar el problema de dejar una variable vacia en mi fichero de configuración (file.conf), al no conseguir evitar este problema con expresiones regulares hemos creado unas sentencias if que permitirán que pasen solo las políticas que tengan todas las variables introducidas.
Leyendo fichero .conf
En el anterior post comentamos el que supuestamente será nuestro fichero de configuración, sinó al menos un esbozo de él. Ahora mismo estoy trabajando en como poder leer tal fichero de configuración, y que solo admita las lineas de configuración que cumplan todos los requisitos estipulados, estamos depurando al máximo este código para que no pueda ocurrir ningún tipo de error, y que tan solo lea las líneas que sean totalmente correctas respecto a nuestros criterios. Una vez resuelto esto, el problema será aislar todos estos datos y conseguir una manera para trabajar con ellos, debido a que el número de políticas podría ser infinito nos encontramos con que el número de variables no es un número fijo, cosa que nos genera un problema que debemos solucionar.
jueves, 10 de septiembre de 2009
Creando el fichero de configuración
Para tener un fichero de configuración editable y entendible por el usuario, y que el error en la edición por parte del usuario no provoque fallos graves en la ejecución, vamos a crear un fichero que luego leeremos con awk.
A continuación explicamos su estructura y ponemos 3 ejemplos.
Los primeros 3 caracteres nos indican el tamanyo a usar por la politica, como ejemplos tenemos el primero 010, que indicara o bien el 10% o 10 MB, KB o GB, Siempre que no se usen las 3 cifras se rellenaran ceros por delante.
El cuarto caracter indicara si es un porcentaje (%), o si son MB (M), GB (G), KB (K), etc.
El quinto caracter indicara si el espacio solicitado en los 4 primeros caracteres se refiere a la cache (C), o al disco (F), indicando si el porcentaje o el tamanyo seran de espacio en la cache o de espacio en el disco.
Tras el primer tabulador, los siguientes caracteres que encontremos nos especificaran el tipo de documento que queremos cachear, documentos de word, jpg, excel, etc, si escribimos none indicara que queremos cachear cualquier tipo de documento en esta politica.
Tras el segundo tabulador los caracteres que encontramos nos indicaran si queremos delimitar en algun tamanyo los archivos que cacheara la politica, si en el primer caracter especificamos (<) indicamos que cachee todos los ficheros de menor tamanyo que..., si especificamos (>) indicamos que cachee los ficheros de mayor tamanyo que ..., tb podremos dar la opcion de no restringir por tamanyo de fichero, es lo que hace la tercera politica.
Por ultimo tras el tercer tabulador indicaremos skip/count/skip/count/bs, skip sera los bloques iniciales que se salte al hacer dd, donde iniciara el cacheo del fichero, count indicara cuantos bloques cacheara desde donde marque el primer skip, el segundo skip marcara indicara cuantos bloques se saltara desde acabar el primer count, y el segundo count indicara cuantos bloques cacheara desde donde marco el segundo skip, por ultimo tendremos bs que marcara el tamanyo de los bloques, cada uno de estos estara definido por dos caracteres poniendo a 0 el primero en caso de ser una cifra menor a 10, en el ultimo caso, bs anayadira al final de estos dos caracteres un tercero para indicar KB (K), MB (M), etc, en caso de querer cachear todo el fichero sin saltos se marcaran skip/count/skip/count/bs de esta forma 00/00/00/00/02K siendo necesarios estos 3 ultimos caracteres
para indicar cada cuanto tamanyo hara los saltos el dd para cachear.
010%F doc <50k 02/04/02/02/02K 055XF none >30M 03/03/02/03/05K
029%F jfkdlsj82jlsa =00M 02/02/02/05/05M
A continuación explicamos su estructura y ponemos 3 ejemplos.
Los primeros 3 caracteres nos indican el tamanyo a usar por la politica, como ejemplos tenemos el primero 010, que indicara o bien el 10% o 10 MB, KB o GB, Siempre que no se usen las 3 cifras se rellenaran ceros por delante.
El cuarto caracter indicara si es un porcentaje (%), o si son MB (M), GB (G), KB (K), etc.
El quinto caracter indicara si el espacio solicitado en los 4 primeros caracteres se refiere a la cache (C), o al disco (F), indicando si el porcentaje o el tamanyo seran de espacio en la cache o de espacio en el disco.
Tras el primer tabulador, los siguientes caracteres que encontremos nos especificaran el tipo de documento que queremos cachear, documentos de word, jpg, excel, etc, si escribimos none indicara que queremos cachear cualquier tipo de documento en esta politica.
Tras el segundo tabulador los caracteres que encontramos nos indicaran si queremos delimitar en algun tamanyo los archivos que cacheara la politica, si en el primer caracter especificamos (<) indicamos que cachee todos los ficheros de menor tamanyo que..., si especificamos (>) indicamos que cachee los ficheros de mayor tamanyo que ..., tb podremos dar la opcion de no restringir por tamanyo de fichero, es lo que hace la tercera politica.
Por ultimo tras el tercer tabulador indicaremos skip/count/skip/count/bs, skip sera los bloques iniciales que se salte al hacer dd, donde iniciara el cacheo del fichero, count indicara cuantos bloques cacheara desde donde marque el primer skip, el segundo skip marcara indicara cuantos bloques se saltara desde acabar el primer count, y el segundo count indicara cuantos bloques cacheara desde donde marco el segundo skip, por ultimo tendremos bs que marcara el tamanyo de los bloques, cada uno de estos estara definido por dos caracteres poniendo a 0 el primero en caso de ser una cifra menor a 10, en el ultimo caso, bs anayadira al final de estos dos caracteres un tercero para indicar KB (K), MB (M), etc, en caso de querer cachear todo el fichero sin saltos se marcaran skip/count/skip/count/bs de esta forma 00/00/00/00/02K siendo necesarios estos 3 ultimos caracteres
para indicar cada cuanto tamanyo hara los saltos el dd para cachear.
010%F doc <50k 02/04/02/02/02K 055XF none >30M 03/03/02/03/05K
029%F jfkdlsj82jlsa =00M 02/02/02/05/05M
miércoles, 8 de julio de 2009
Actualizando nfs-utils
Tras recompilar el kernel a la versión 2.6.30-rc1 nos damos cuenta de que nuestro módulo de Cache FS ha dejado de cachear, tras muchas consultas en los foros, y muchos emails de ida y vuelta, descubrimos que posiblemente sea debido a que la versión de nfs-utils no es lo suficientemente actual como para entender el parámetro fsc al montar. Para actualizar nos descargamos la última versión desde http://sourceforge.net/projects/nfs/files/ y descomprimimos el paquete, al hacer un ./configure dentro de las carpetas nos salta un error de dependencias de libevent, nos bajamos la última versión que aparece aquí: http://monkey.org/~provos/libevent/, instalamos sin problemas haciendo ./configure && make y make install, volvemos a ejecutar el paso anterior de ./configure dentro de la carpeta nfs-utils nos salta un error acerca de soporte sobre nfsv4, como realmente no lo necesitamos, miramos la configuración del makefile, y vemos que existe la opción --disable-nfsv4, así que ejecutamos esta vez la orden ./configure --disable-nfsv4, no salta un error parecido pero con gss, y también encontramos la opción de desabilitar cosa que hacemos al volver a ejecutar ./configure --disable-nfsv4 --disable-gss, después de ejecutar este comando nos devuelve un error comentándonos que se necesita libblkid, buscamos los paquetes en los que se encuentra con yum provides libblkid* y tras el resultado ejecutamos yum install e2fsprogs-libs.i386 y yum install e2fsprogs-devel.i386, después de instalar estos, ejecutamos de nuevo ./configure --disable-nfsv4 --disable-gss y esta vez funciona sin problema, seguimos instalando nfs-utils con los comandos make y make install, y finaliza la instalación sin problemas.
Tras haber actualizado nfs-utils probamos a ver si funciona correctamente el caching y efectivamente vuelve a funcionar correctamente.
Tras haber actualizado nfs-utils probamos a ver si funciona correctamente el caching y efectivamente vuelve a funcionar correctamente.
domingo, 31 de mayo de 2009
Recompilando el Kernel
Mirando la documentación de Cache FS
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/filesystems/caching/fscache.txt;hb=0882e8dd3aad33eca41696d463bb896e6c8817eb
Nos encontramos con la posibilidad de añadir estadísticas a Cache-FS, esta opción la podemos habilitar recompilando el kernel y modificando la configuración antes de compilar. Deberíamos habilitar estas dos opciones:
CONFIG_FSCACHE_STATS=y
CONFIG_FSCACHE_HISTOGRAM=y
Vamos a explicar los pasos para recompilar el kernel, en nuestro caso sobre CentOS 5.2, y la versión 2.6.30-rc1. Lo primero que hacemos es descargarla desde www.kernel.org, descargamos el tar.bz2 desde http://www.kernel.org/pub/linux/kernel/v2.6/testing/
Copiamos el archivo descargado /usr/src/ y lo descomprimimos con tar xvfj linux-2.6.30-rc1.tar.bz2.
Antes de seguir debemos saber que es necesario que tengamos instalado gcc, y mkinitrd, en caso de no tenerlas las instalaremos con yum en nuestro caso, en otras distros con apt-get, una vez instalados, haremos las siguientes instrucciones:
>make mrproper --> Borramos archivos de configuraciones antiguas
>make menuconfig --> Iniciamos un entorno gráfico para configurar las opciones que se instalarán con el kernel o como módulos (existen otros modos, para este son necesarias las liberias ncurses, yum install ncurses-devel).
Pasos para configurar el histograma y las estadísticas de Cache-FS
Continuamos con estas instrucciones:
>make clean --> Limpia restos de anteriores compilaciones
>make dep --> Establece las dependencias entre los módulos seleccionados
>make bzImage --> Compila el kernel y crea una imagen en el boo
>make modules --> Compila los módulos
>make modules_install --> Instala los módulos
>make install
Con esto debería estar todo, al reiniciar nos aparecerá nuestra nueva versión del kernel, y al iniciar el servicio de Cache-FS en /proc/fs/ tendremos los archivos stats e histogram.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/filesystems/caching/fscache.txt;hb=0882e8dd3aad33eca41696d463bb896e6c8817eb
Nos encontramos con la posibilidad de añadir estadísticas a Cache-FS, esta opción la podemos habilitar recompilando el kernel y modificando la configuración antes de compilar. Deberíamos habilitar estas dos opciones:
CONFIG_FSCACHE_STATS=y
CONFIG_FSCACHE_HISTOGRAM=y
Vamos a explicar los pasos para recompilar el kernel, en nuestro caso sobre CentOS 5.2, y la versión 2.6.30-rc1. Lo primero que hacemos es descargarla desde www.kernel.org, descargamos el tar.bz2 desde http://www.kernel.org/pub/linux/kernel/v2.6/testing/
Copiamos el archivo descargado /usr/src/ y lo descomprimimos con tar xvfj linux-2.6.30-rc1.tar.bz2.
Antes de seguir debemos saber que es necesario que tengamos instalado gcc, y mkinitrd, en caso de no tenerlas las instalaremos con yum en nuestro caso, en otras distros con apt-get, una vez instalados, haremos las siguientes instrucciones:
>make mrproper --> Borramos archivos de configuraciones antiguas
>make menuconfig --> Iniciamos un entorno gráfico para configurar las opciones que se instalarán con el kernel o como módulos (existen otros modos, para este son necesarias las liberias ncurses, yum install ncurses-devel).
Pasos para configurar el histograma y las estadísticas de Cache-FS
Continuamos con estas instrucciones:
>make clean --> Limpia restos de anteriores compilaciones
>make dep --> Establece las dependencias entre los módulos seleccionados
>make bzImage --> Compila el kernel y crea una imagen en el boo
>make modules --> Compila los módulos
>make modules_install --> Instala los módulos
>make install
Con esto debería estar todo, al reiniciar nos aparecerá nuestra nueva versión del kernel, y al iniciar el servicio de Cache-FS en /proc/fs/ tendremos los archivos stats e histogram.
miércoles, 15 de abril de 2009
GENERAL FILESYSTEM CACHING
Cache Filesystem está diseñado con el propósito de hacer cache para sistemas de ficheros de red, sin embargo se podría usar para cachear otras cosas como ISO9660 Filesystems.
El módulo FS-Cache media entre estos sistemas de ficheros, de red o no, y los repositorios o backends, como CacheFS o Cachefiles.
Visto de otra forma FS-Cache es un módulo que provee de capacidad para cachear a sistemas de ficheros en red, haciendo esto de manera transparente para el usuario.
Como podemos ver VFS(Virtual File System) comunica el sistema de ficheros de red (en adelante netfs) con el proceso. VFS proporciona una API para acceder a diferentes sistemas de ficheros, proporciona una forma uniforme de visualizar ficheros de varias fuentes. (ver http://commons.apache.org/vfs/).
Como podemos ver en el dibujo, el server se comunica a través de netfs(en este caso NFS), y FS-Cache media entre netfs y los backends, que estan en el disco local, la gestión de los datos en local es controlada por el demonio cachefilesd.
FS-Cache no sigue la idea de cargar completamente cada archivo abierto de un netfs en la cache antes de permitir que este sea accedido y entonces servir las páginas debido a que:
1- Podría ser práctico trabajar sin cache.
2- El tamaño de un fichero accesible no debería estar limitado por el tamaño de la cache.
3- La combinación de todos los tamaños de los ficheros abiertos (incluyendo librerías mapeadas) no debería depender del tamaño de la cache.
4- El usuario no debería estar forzado a descargar completamente un fichero para acceder a una pequeña parte del fichero. En vez de servir la cache fuera en trozos de PAGE_SIZE.
FS-Cache proporciona las siguientes características:
1- Se puede usar más de una cache en el mismo momento. Las caches pueden ser seleccionadas mediante el uso de etiquetas.
2- Se pueden añadir o eliminar caches en cualquier momento.
3- Netfs proporciona una interfaz que permite retirar las características de Cache Filesystem a un fichero.
4- La interfaz de netfs devuelve el mínimo de errores posible, refiriendo que esta
pertenezca ajena a estos.
5- Las cookies son usadas para representar índices, ficheros y otros objetos a netfs. La cookie simple es solo un puntero nulo, indicando que no hay nada cacheado ahí.
6- Netfs tiene permitido proponer -dinámicamente- cualquier jerarquía de índices que desee, aunque debería controlar y ser consciente de que la función de búsqueda de índices es recursiva, el espacio de la pila es limitado, y los índices solo pueden ser hijos de índices.
7- Los datos de entrada y salida están hechos directamente para y por las páginas de netfs. Netfs indica que la página A esta en el índice B y es representada por la cookie C, y este debería ser leído o escrito. El backend o repositorio de cache debería o no debería empezar entradas y salidas en esa página, pero si lo hace una rellamada a netfs será invocada para indicar la finalización. Las entradas y salidas pueden ser síncronas o asíncronas.
8- Las cookies pueden ser "retiradas", quedar liberadas. En este punto FS-Cache marca a estas como obsoletas y la jerarquía de índices que existe en ese momento podrá ser reciclada.
9- Netfs proporciona una función de equivalencia para búsquedas de índices. Nos dirá si coincide o no, esto especificará si la entrada tiene que ser actualizada o borrada.
10- En medida de lo posible esta hecho asíncronamente.
El módulo FS-Cache media entre estos sistemas de ficheros, de red o no, y los repositorios o backends, como CacheFS o Cachefiles.
Visto de otra forma FS-Cache es un módulo que provee de capacidad para cachear a sistemas de ficheros en red, haciendo esto de manera transparente para el usuario.
Como podemos ver VFS(Virtual File System) comunica el sistema de ficheros de red (en adelante netfs) con el proceso. VFS proporciona una API para acceder a diferentes sistemas de ficheros, proporciona una forma uniforme de visualizar ficheros de varias fuentes. (ver http://commons.apache.org/vfs/).
Como podemos ver en el dibujo, el server se comunica a través de netfs(en este caso NFS), y FS-Cache media entre netfs y los backends, que estan en el disco local, la gestión de los datos en local es controlada por el demonio cachefilesd.
FS-Cache no sigue la idea de cargar completamente cada archivo abierto de un netfs en la cache antes de permitir que este sea accedido y entonces servir las páginas debido a que:
1- Podría ser práctico trabajar sin cache.
2- El tamaño de un fichero accesible no debería estar limitado por el tamaño de la cache.
3- La combinación de todos los tamaños de los ficheros abiertos (incluyendo librerías mapeadas) no debería depender del tamaño de la cache.
4- El usuario no debería estar forzado a descargar completamente un fichero para acceder a una pequeña parte del fichero. En vez de servir la cache fuera en trozos de PAGE_SIZE.
FS-Cache proporciona las siguientes características:
1- Se puede usar más de una cache en el mismo momento. Las caches pueden ser seleccionadas mediante el uso de etiquetas.
2- Se pueden añadir o eliminar caches en cualquier momento.
3- Netfs proporciona una interfaz que permite retirar las características de Cache Filesystem a un fichero.
4- La interfaz de netfs devuelve el mínimo de errores posible, refiriendo que esta
pertenezca ajena a estos.
5- Las cookies son usadas para representar índices, ficheros y otros objetos a netfs. La cookie simple es solo un puntero nulo, indicando que no hay nada cacheado ahí.
6- Netfs tiene permitido proponer -dinámicamente- cualquier jerarquía de índices que desee, aunque debería controlar y ser consciente de que la función de búsqueda de índices es recursiva, el espacio de la pila es limitado, y los índices solo pueden ser hijos de índices.
7- Los datos de entrada y salida están hechos directamente para y por las páginas de netfs. Netfs indica que la página A esta en el índice B y es representada por la cookie C, y este debería ser leído o escrito. El backend o repositorio de cache debería o no debería empezar entradas y salidas en esa página, pero si lo hace una rellamada a netfs será invocada para indicar la finalización. Las entradas y salidas pueden ser síncronas o asíncronas.
8- Las cookies pueden ser "retiradas", quedar liberadas. En este punto FS-Cache marca a estas como obsoletas y la jerarquía de índices que existe en ese momento podrá ser reciclada.
9- Netfs proporciona una función de equivalencia para búsquedas de índices. Nos dirá si coincide o no, esto especificará si la entrada tiene que ser actualizada o borrada.
10- En medida de lo posible esta hecho asíncronamente.
martes, 3 de febrero de 2009
Instalando y configurando Cache-FS
Después de bajarnos los tar.gz de cachefilesd del repositorio que encontramos, al descomprimir encontramos un archivo howto.txt, nos disponemos a seguirlo para intentar instalar el módulo.
Seguimos las instrucciones, y creamos la carpeta fscache dentro de var, /var/fscache, acto seguido copiamos en /etc el archivo cachefilesd.conf, al abrir este archivo vemos que tiene configurada la carpeta /var/fscache, que hemos creado anteriormente, nos dice que el siguiente paso que tenemos que realizar es iniciar el servicio con el comando: service cachefilesd start, nos devuelve como respuesta que no encuentra el comando. Posteamos en el mailing list y nos responden que ese error sea debido seguramente a que no hemos compilado el código de cachefilesd.
Después de la respuesta hacemos diferentes pruebas, creando una máquina virtual con Fedora Core 10, en la cuál en agregar y quitar programas encontramos un paquete cachefilesd-0.7, por tanto decidimos bajarnos del repositori esa versión de cachefilesd y reintentarlo compilar de nuevo, pero seguimos con el mismo error.
Nos damos cuenta que esa versión es para Fedora Core 7, y por tanto bajamos una imagen de la versión y la instalamos en una nueva máquina virtual, una vez instalada, instalamos todas las actualizaciones como en el resto de máquinas virtuales. Al terminar volvemos a probar, y vemos que sigue dandonos el mismo error.
Vemos que en el repositorio hay algunos rpm, y decidimos bajarnoslos e intentar ejecutarlos para ver si esto soluciona nuestro problema, pero para la única versión que no encontramos los rpm es casualmente para la de cachefilesd-0.7, por tanto nos bajamos otra versión de los tar.gz de cachefilesd, y su correspondiente rpm. Al ejecutar los rpm nos devuelve que no puede instalar los paquetes.
Después de todas estas pruebas, con Ubuntu conseguimos compilar correctamente el código de cachefilesd-0.9 con las siguientes instrucciones:
>make
>sudo make install
el cuál nos devuelve el error ya comentado, descubrimos que es debido a que nos faltan librerias, que instalamos con el comando:
>sudo apt-get install build-essential
Al compilar de nuevo nos funciona y probamos a iniciar el servicio de nuevo con el comando:
>service cachefilesd start
esta vez nos devuelve el mensaje:
el programa <> puede encontrarse en los siguientes paquetes
debian-helper-scripts
sysvconfig
y que podemos instalarlos con la instrucción sudo apt-get install.
Hacemos esto con ambos paquetes, y volvemos a intentar iniciar el servicio. Esta vez nos devuelve que no puede encontrar cachefilesd en /etc/init.d, y movemos nuestra carpeta cachefilesd-0.9 a /etc/init.d/cachefilesd, y al ejecutar el comando para iniciar el servicio, ya lo inicia correctamente.
Seguimos las instrucciones, y creamos la carpeta fscache dentro de var, /var/fscache, acto seguido copiamos en /etc el archivo cachefilesd.conf, al abrir este archivo vemos que tiene configurada la carpeta /var/fscache, que hemos creado anteriormente, nos dice que el siguiente paso que tenemos que realizar es iniciar el servicio con el comando: service cachefilesd start, nos devuelve como respuesta que no encuentra el comando. Posteamos en el mailing list y nos responden que ese error sea debido seguramente a que no hemos compilado el código de cachefilesd.
Después de la respuesta hacemos diferentes pruebas, creando una máquina virtual con Fedora Core 10, en la cuál en agregar y quitar programas encontramos un paquete cachefilesd-0.7, por tanto decidimos bajarnos del repositori esa versión de cachefilesd y reintentarlo compilar de nuevo, pero seguimos con el mismo error.
Nos damos cuenta que esa versión es para Fedora Core 7, y por tanto bajamos una imagen de la versión y la instalamos en una nueva máquina virtual, una vez instalada, instalamos todas las actualizaciones como en el resto de máquinas virtuales. Al terminar volvemos a probar, y vemos que sigue dandonos el mismo error.
Vemos que en el repositorio hay algunos rpm, y decidimos bajarnoslos e intentar ejecutarlos para ver si esto soluciona nuestro problema, pero para la única versión que no encontramos los rpm es casualmente para la de cachefilesd-0.7, por tanto nos bajamos otra versión de los tar.gz de cachefilesd, y su correspondiente rpm. Al ejecutar los rpm nos devuelve que no puede instalar los paquetes.
Después de todas estas pruebas, con Ubuntu conseguimos compilar correctamente el código de cachefilesd-0.9 con las siguientes instrucciones:
>make
>sudo make install
el cuál nos devuelve el error ya comentado, descubrimos que es debido a que nos faltan librerias, que instalamos con el comando:
>sudo apt-get install build-essential
Al compilar de nuevo nos funciona y probamos a iniciar el servicio de nuevo con el comando:
>service cachefilesd start
esta vez nos devuelve el mensaje:
el programa <
debian-helper-scripts
sysvconfig
y que podemos instalarlos con la instrucción sudo apt-get install
Hacemos esto con ambos paquetes, y volvemos a intentar iniciar el servicio. Esta vez nos devuelve que no puede encontrar cachefilesd en /etc/init.d, y movemos nuestra carpeta cachefilesd-0.9 a /etc/init.d/cachefilesd, y al ejecutar el comando para iniciar el servicio, ya lo inicia correctamente.
domingo, 1 de febrero de 2009
Entendiendo el funcionamiento
Cache File System utiliza un medio local de almacenamiento(por ejemplo un disco duro local) para cachear otros medios, generalmente remotos(por ejemplo NFS).
Los motivos para usar una cache son varios.
Algunos medios son lentos, como:
- Servicios de red: AFS, NFS.
- Dispositivos lentos: CDs, DVDs.
Otros medios son rápidos como:
- Discos locales.
- R.A.M.
Podemos usar medios más rápidos como cache para acelerar el acceso a los medios más lentos.
También nos puede servir con medios de red, si perdemos la conexión mantenemos en cache el trabajo que estabamos haciendo y por tanto no lo perdemos.
Los motivos para usar una cache son varios.
Algunos medios son lentos, como:
- Servicios de red: AFS, NFS.
- Dispositivos lentos: CDs, DVDs.
Otros medios son rápidos como:
- Discos locales.
- R.A.M.
Podemos usar medios más rápidos como cache para acelerar el acceso a los medios más lentos.
También nos puede servir con medios de red, si perdemos la conexión mantenemos en cache el trabajo que estabamos haciendo y por tanto no lo perdemos.
sábado, 31 de enero de 2009
Creando la Máquina Virtual
Hemos creado una máquina virtual sobre Windows XP, con Virtual Box, en ella hemos instalado Ubuntu 64 bits.
Una vez instalado el S.O. correctamente hemos descargado en ella desde el repositorio anteriormente mencionado el archivo:
cachefilesd-0.9.tar.bz2
Descomprimimos el paquete y vemos en el contenido un fichero howto.txt, el cuál hemos ido
leyendo y siguiendo, hasta que nos ha pedido iniciar el servicio cachefilesd, y esto ha dado un error.
Por otro lado hemos encontrado otras páginas que tienen un howto de como configurar Cache-FS.
http://docs.hp.com/en/B1031-90061/ch04s03.html?btnNext=next%A0%BB
http://docs.sun.com/app/docs/doc/817-5093/fscachefs-80158?l=en&a=view
Las cuales nos dicen de ejecutar el comando:
cfsadmin-c cache_directory
Este comando nos devuelve el mensaje de que no se encuentra la orden, debido a estos fallos, pensamos que tal vez estas guías estén diseñadas para otra distro de Linux, por eso nos ponemos a descargar Fedora.
Una vez instalado el S.O. correctamente hemos descargado en ella desde el repositorio anteriormente mencionado el archivo:
cachefilesd-0.9.tar.bz2
Descomprimimos el paquete y vemos en el contenido un fichero howto.txt, el cuál hemos ido
leyendo y siguiendo, hasta que nos ha pedido iniciar el servicio cachefilesd, y esto ha dado un error.
Por otro lado hemos encontrado otras páginas que tienen un howto de como configurar Cache-FS.
http://docs.hp.com/en/B1031-90061/ch04s03.html?btnNext=next%A0%BB
http://docs.sun.com/app/docs/doc/817-5093/fscachefs-80158?l=en&a=view
Las cuales nos dicen de ejecutar el comando:
cfsadmin-c cache_directory
Este comando nos devuelve el mensaje de que no se encuentra la orden, debido a estos fallos, pensamos que tal vez estas guías estén diseñadas para otra distro de Linux, por eso nos ponemos a descargar Fedora.
viernes, 30 de enero de 2009
Comenzando a trabajar
Antes de la creación del blog hemos estado haciendo algo de investigación, buscando websites que hablen sobre Cache-FS, las cuales nos puedan ayudar en nuestro trabajo.
Nos hemos subscrito al mailing list de Cache-FS.
http://www.redhat.com/mailman/listinfo/linux-cachefs
En él hemos posteado para conseguir información y estamos pendientes de respuesta.
En Wikipedia también hemos encontrado mas información, entre las que destacán la dirección de correo de David Howells, que desarrollo la primera implementación de Cache File System sobre Linux, reescribiendo el código de Sun Microsystems, la empresa creadora de Cache File System.
Le hemos enviado un email demandándole ayuda, con ciertas preguntas, también estamos esperando respuesta.
Y también en Wikipedia, encontramos el repositorio de Cache File System de David Howells.
http://people.redhat.com/~dhowells/cachefs/
Nos hemos subscrito al mailing list de Cache-FS.
http://www.redhat.com/mailman/listinfo/linux-cachefs
En él hemos posteado para conseguir información y estamos pendientes de respuesta.
En Wikipedia también hemos encontrado mas información, entre las que destacán la dirección de correo de David Howells, que desarrollo la primera implementación de Cache File System sobre Linux, reescribiendo el código de Sun Microsystems, la empresa creadora de Cache File System.
Le hemos enviado un email demandándole ayuda, con ciertas preguntas, también estamos esperando respuesta.
Y también en Wikipedia, encontramos el repositorio de Cache File System de David Howells.
http://people.redhat.com/~dhowells/cachefs/
Introducción
Antes de nada presentar este blog, y explicar cual es el motivo de su creación.
Este será un blog dedicado al trabajo de investigación sobre Cache File System. En él se irán posteando informaciones encontradas sobre el tema, así como los diferentes desarrollos que se irán implementando, y los avances que se vayan realizando. Este blog nace con este objetivo y con el de hacer un seguimiento sobre mi proyecto final de carrera.
Este será un blog dedicado al trabajo de investigación sobre Cache File System. En él se irán posteando informaciones encontradas sobre el tema, así como los diferentes desarrollos que se irán implementando, y los avances que se vayan realizando. Este blog nace con este objetivo y con el de hacer un seguimiento sobre mi proyecto final de carrera.
Suscribirse a:
Entradas (Atom)