Closed moracontreras closed 4 months ago
Hola buenas!
Voy a tratar de ir de a pedazos para organizar la consulta
Yo había preguntado ya en un soporte y me dijeron que debía usar ftruncate (o que se me recomendaba su uso)
Cuando se recomendó ftruncate seguramente fue para la creación del archivo bloques.dat y no tanto para implementar la función truncate del TP.
Yo lo que había pensado siguiendo mi lógica anterior era que, si se tenía que agrandar el archivo entonces iba a ponerle un uno a más bloques en el bitmap y cambiar el tamaño del archivo en el metadata y en caso de que se achicara el archivo entonces iba a desasignar bloques poniendo 0 en bitmap y borrar el contenido en el archivo bloques.
Sobre poner en 0 al achicar, no tienen que tocar el contenido de bloques para "borrar", simplemente marcan el bloque como libre y listo. Sobre como agrandar un archivo estas en lo correcto, con lo único que aclaro es que puede ser que haya bloques libres pero no sean contiguos en ese caso ustedes tienen que compactar para poder tener todos los bloques libres juntos y así poder extender este archivo
Además, quería saber si al eliminar un archivo, está bien colocar 0 en los bytes que ocupada del archivo de bloques.
Como dije antes no tienen que tocar el contenido de los bloques para borrar en ningún caso, el contenido de los bloques lo van a tocar con un WRITE explicito o cuando compacten al tener que mover bloques.
Última pregunta, si se quiere leer cierta cantidad de bytes de un archivo desde cierta posición y en realidad desde esa posición hay menos bytes asignados a ese archivo, hago que lea lo máximo posible correspondiente a ese archivo, es decir hasta el final aunque faltarían bytes, o devuelvo un error?
No es un caso que vayamos a probar, si quieren controlarlo para estar seguros que estan ejecutando bien las pruebas pueden poner un mensaje de error para identificar el caso
Saludos!
Dejo un issue que se habla de compactación con un soporte gráfico que puede ayudar a entender esa parte https://github.com/sisoputnfrba/foro/issues/4017
Buenísimo, gracias! Te hago otra consulta, está bien si cada vez que haya que crear un archivo en realidad sólo creo el archivo metadata? leí en otros issues que crean archivos de usuario pero les pusieron que FS write por ejemplo solo toca bloques.dat y no el archivo de usuario entonces pensé que no era necesario ese archivo de usurario
Otra pregunta, estaría bien a medida que se crea una metadata se la coloque en una lista de metadatas para despues si tengo que modificar el tamaño de una acceder directo a esa? el problema con eso es que yo inicialmente pensé que se podía tomar como una única metadata de variables globales que iba cambiando en cada ejecución para así poder usar las funciones de config y acceder al bloque inicial con una variable global, entonces eso ya no me serviría
Te hago otra consulta, está bien si cada vez que haya que crear un archivo en realidad sólo creo el archivo metadata? leí en otros issues que crean archivos de usuario pero les pusieron que FS write por ejemplo solo toca bloques.dat y no el archivo de usuario entonces pensé que no era necesario ese archivo de usurario.
Tienen que marcar como ocupado el bloque correspondiente en el bitmap también.
No termino de entender que seria el archivo de usuario 🤔
Otra pregunta, estaría bien a medida que se crea una metadata se la coloque en una lista de metadatas para despues si tengo que modificar el tamaño de una acceder directo a esa? el problema con eso es que yo inicialmente pensé que se podía tomar como una única metadata de variables globales que iba cambiando en cada ejecución para así poder usar las funciones de config y acceder al bloque inicial con una variable global, entonces eso ya no me serviría
No me lo tomes a mal, pero no estoy en tu cabeza como para saber el contexto preciso de lo que me preguntas, así que si me ordenas el mensaje es mucho más fácil 😅
Intento responder lo que entiendo:
Si, estaría bien tener una lista de metadatas, lo que se podría hacer paralelismo en la teoría como la tabla global de archivos (simplificada)
Lo que si está lista es variable tanto en que bloque inicial tiene un archivo (compactación), como en cantidad de archivos, también tienen que considerar el caso de que un FS inicie y ya tengan archivos creados de una ejecución previa
Espero haber entendido bien la pregunta
Respecto a los archivos de usuario, por lo que entiendo es que además del metadata crean literalmente un archivo como tal con el nombre correspondiente.
Eso es el comportamiento que deben tener, al recibir un IO_FS_CREATE van a tener que:
Luego al iniciar el FS lo primero que tienen que hacer es validar si ya existe en esa ruta un archivo bloques.dat, bitmap y todos los posibles archivos de metadata y poder operar con los mismos
claro, ese archivo es directo el metadata, no hay un cuarto tipo de archivo. perfecto, muchas gracias!
Hola! Todo bien? Estaba haciendo las funciones de IO para FS y me mezclé. Yo pensaba que siempre que haya que hacer una función sobre un archivo, debía ser en realidad sobre el archivo bloques. Ejemplo si quiero leer un archivo, en realidad accedo al archivo bloques, apunto a donde corresponda y lo leo. Todo tenía lógica, con todas las funciones, hasta que me puse a hacer la de truncar archivo. Yo había preguntado ya en un soporte y me dijeron que debía usar ftruncate (o que se me recomendaba su uso). El tema es que, por lo que entiendo, para usarla sí debería trabajar sobre el archivo como tal y no sobre el archivo de bloques, o no? Yo lo que había pensado siguiendo mi lógica anterior era que, si se tenía que agrandar el archivo entonces iba a ponerle un uno a más bloques en el bitmap y cambiar el tamaño del archivo en el metadata y en caso de que se achicara el archivo entonces iba a desasignar bloques poniendo 0 en bitmap y borrar el contenido en el archivo bloques. CUestión, ya no sé que está bien y qué no, si me pueden por favor reorganizar las ideas buenísimo. Además, quería saber si al eliminar un archivo, está bien colocar 0 en los bytes que ocupada del archivo de bloques. Última pregunta, si se quiere leer cierta cantidad de bytes de un archivo desde cierta posición y en realidad desde esa posición hay menos bytes asignados a ese archivo, hago que lea lo máximo posible correspondiente a ese archivo, es decir hasta el final aunque faltarían bytes, o devuelvo un error? Desde ya, muchas gracias!