The role of a File SystemUn File System (FS) mantiene el contenido del file en dos lugares: totalmente en tape, parcialmente en memoria (buffers). Ambos no estan sincronizados todo el tiempo, pero deben estarlo en el momento apropiado para evitar perdida o corrupcion de dato.
La principal mision del FS es proveer la sincronia entre BUFFERs y TAPES de tal suerte que el software cliente pueda tratar los files en terminos de bytes, no de bloques. El FS tiene pues dos caras: de cara al tape, opera en terminos de bloques; de cara al cliente, opera en terminos de bytes.
De momento no voy a pensar en "CACHE", es decir, no me interesa ganar eficiencia a costa de poder volver a leer una parte del file directamente de memoria sin necesidad de traerla de disco. Esto es porque mis files son secuenciales y por tanto ese evento (leer repetidamente) no ha de ocurrir a menudo. Solo voy a implementar "BUFFERS" con el fin antes mencionado.
Data Structures
Lo mas simple es que el BUF se ocupe tan solo de contener un bloque, pero esto tal vez resulte demasiado ineficiente. Una estructura mas prometedora (aunque mucho mas complicada) es una lista de structuras como esta:
* Pointer to BUF
* BUF size
* Status (leido de tape, modificado en memoria, escrito a tape, siendo leido en este momento, etc)
* File Pointer
En memoria dinamica aparte (apuntado por 'Pointer to BUF') se ubican los buffers mismos, cada uno conteniendo un bloque de file. No seran muchos, tal vez cuatro o cinco.
Para el cliente, el file es una secuencia de bytes. El FS recibe requests de escritura o lectura y se encarga de llenar convenientemente los buffers, asi como de leer/escribir de/a tape cuando lo estime oportuno.
Esto apunta a un software bastante sofisticado, tal vez deba pensar en algo mas simple, de ser posible.
|
