Estoy estudiando para el final de Sistemas Operativos de este martes (19 de febrero), y estoy con unos ejercicios de Filesystem que me dan algunas dudas. Los posteo de a poco acá con mis reflexiones a ver qué les parece.

Final 28/02/2012 - Disponible aquí
Enunciado:
Se dispone de un disco de 7000 pistas y 4 platos de capacidad formateado para que trabaje con un sistema de archivos tipo UNIX cuyas características se describen a continuación:

• Tamaño de bloque (lógico/físico): 2 kilobytes
• Tamaño de la dirección de bloque: 48 bits
• Número de i-nodos: 7000
• Campos del i-nodo: a) atributos del archivo: 976 bytes. b) 5 punteros directos. c) 1 puntero indirecto simple. d) 1 punteros indirecto doble. e) 1 puntero indirecto triple.
  

Se pide:

• ¿Qué tamaño tiene el disco?
• Suponiendo que el i-nodo está en memoria y que un archivo ocupa en 37658907 bytes memoria (dixit). ¿Cuántos accesos a disco se necesitan para grabar este archivo por primera vez en el disco?
• Calcule el tamaño máximo que podría ocupar el filesystem de esta versión de Unix y el tamaño actual del filesystem.
• Si se trabaja con páginas en memoria de 1K y se desa armar una partición de swap para paginación por demanda, cuál sería el mejor filesystem y qué tamaño de bloque en disco debería tener. Justifique su respuesta.
  

Solución tentativa:
a) La fórmula que usaría es:
Tamaño del disco = Pistas * SectoresPorPista * TamañoDelSector
El problema es que no tengo el tamaño del sector. Intuyo que será de 2048 bytes = 2 kilobytes, ya que dice que el tamaño del bloque lógico y físico es de 2 Kb. Ahora, una cosa es un bloque y otra, un sector... pero puede que coincidan. Si estoy en lo cierto, entonces el tamaño sería:
Tamaño del disco = 7000 * 200 * 2 Kb = 2800000 Kb = 2734,375 Mb

b) El archivo pesa 37658907 bytes y como cada bloque es de 2 Kb, ocupa en total 18389 bloques (existe cierto grado de fragmentación interna).
Como el tamaño de la dirección del bloque es 48 bits = 6 bytes, entonces en cada bloque de 2048 bytes entran 341 punteros. Este número ya me parece sospechoso. Suponiendo que está bien, entonces:
cada i-nodo tiene 5 punteros directos, y con el indirecto simple se alcanzan 341 bloques. Es decir 5 + 341 = 346 en total. Quedan acceder entonces 18389 - 346 = 18043 bloques del archivo. Estos 18043 bloques necesitan de (18043/341)=53 lecturas. Se llega a hacer esta cantidad de lecturas accediendo entonces al puntero indirecto doble, y luego a 53 punteros indirectos. En total son:
Accesos = 18389 bloques del archivo + 1 bloque indirecto simple (el del i-nodo) + 1 bloque indirecto doble (el del i-nodo) + 53 bloques indirectos simples (del i-nodo doble anterior) = 18444 bloques en total
Como el i-nodo del archivo estaba en memoria y es necesario escribir la información de los punteros, ¿debo contar el bloque del i-nodo también, haciendo que el total de los bloques sea 18445? Todo esto, por supuesto, suponiendo que los 341 punteros por bloque fueron calculados correctamente.

c) Tamaño total del filesystem = (2^48) * 2 Kb = 524228 Tb (sí, terabytes).
Tamaño actual del filesystem = ???
Esta no tengo idea como se hace. En el final, por escribir algo, haría:
Tamaño actual del filesystem = 7000 i-nodos * (976 bytes del header + 5 punteros directos * 6 bytes + 1 punt indirecto simple * 6 bytes + 1 punt indirecto doble * 6 bytes + 1 punt indirecto triple * 6 bytes) = 7000 i-nodos * 1024 bytes = 7168000 bytes = 7000 Kb ---> Imposible, tiene que estar mal. Más que nada porque eso solamente contempla lo que ocupan los i-nodos en disco, pero no tiene en cuenta el tamaño de cada archivo.

d) Esta es muy teórica. Personalmente, elegiría un filesystem de asignación contigua con marcos iguales al tamaño de la página (1 Kb) y bloques de 4 Kb, fundamentando con el concepto de cercanía de referencia (basado en el principio de cercanía).

Consulta... Lo preguntaste en el Campus Virtual? Porque si bien Adronet esta siempre dando vueltas por acá... Es mas probable que te lo respondan allá mucho mas rápido

Buenas,
a)El primer punto te faltó considerar que existen 4 platos. O sea si tenes cuatro platos tenés 8 superficies/cabezales. Por lo tanto la fórmula sería: 8*7000*200*2Kb=42.7 GB
c) El tamaño actual del filesystem sería: MBR+SuperBlock+Tabla I-nodos+Bit Vector+Vector de I-Nodos= 1 blk+2blk+7000*(976B+5*6B+3*6B)+48GB/2KB +7000b. Este punto igual no estoy completamente seguro, pero creo q es así.
d) Si el tamaño de la página es de 1K el disco SWAP debería tener un filesystem con bloques de 1k de tamaño y asignación contigua. Para cuestiones de rendimiento.

Espero q te sirva.

Gracias Calui por la información.
Me imaginaba que en la a) algo faltaba, pero pensé que las pistas las indicaba por disco, no por plato.
Por lo de la c), te hago tres consultas.
La primera: ¿el MBR y el Superbloque ocupan siempre 1 y 2 bloques, o lo calculaste con alguna fórmula?
Otra: ¿qué es y cómo calculas el vector de I-Nodos?
La última: ¿Cómo calculás el bit-vector?

Gracias otra vez.

La tabla de INodos pesa el tamaño de un INodo x cantidad de INodos, directamente. El tamaño de un INodo lo sacás sumando los bytes de atributos y la cantidad de punteros por el tamaño de cada puntero (siempre en bytes). Como puso calui, lo vas a ver en el cálculo como 7000*(976B+5*6B+3*6B)

El bit vector es netamente un vector de bits que tiene tantos bits como INodos. Este vector se indexa por el Nro. de INodo y el valor indica 1 si el INodo apunta a un bloque libre o 0 si apunta a uno ocupado (esto puede variar, de hecho en Silber. y Stallings es diferente). En el cálculo que hizo calui esto está como 7000b, habría que dividirlo por 8 para que sean Bytes y no Bits.

Me quedan igualmente un par de dudas:
- Me sumo a la pregunta de si el superbloque y el MBR pesan siempre 1bloque y 2 respectivamente
- Seguro el tamaño del FS se calcula así, sumando todas las estructuras? vi algunos ejercicios en los que esto se calcula como la capacidad máxima de direccionamiento del INodo (que suele coincidir con el tamaño máximo de un archivo), Puede que esté equivocado.

EDITO: acabo de encontrar un comentario de Adriano en el Campus Virtual que dice esto:
Tamaño del FS = 2^(tamaño de puntero) x tamaño de bloque. El tamaño REAL te lo va a dar la comparación entre el disco que tenes el el tamaño teórico que calculamos.
Por otro lado, leí en un PDF que el tamaño del superbloque y el MBR es siempre 1 bloque cada uno, aunque depende de la implementación. Alguien podría validar esto?

Con esto tenemos nuevas respuestas, saludos!

Buena info la del bit-vector nnimis, gracias!
La tabla de i-nodos la sé calcular (de hecho, puse la forma de cálculo en el primer post). A lo que me refería es esto:

Cita:MBR + SuperBlock + Tabla I-nodos + Bit Vector + Vector de I-Nodos =
1 blk + 2blk + 7000*(976B+5*6B+3*6B) + 48GB/2KB + 7000b

Fijate que lo que pusiste como bit-vector el lo llama "Vector de i-nodos", además de la "tabla de i-nodos"... que vos, yo y Calui calculamos de la misma forma.
Es decir: estamos todos de acuerdo en la tabla de i-nodos; hay acuerdo sobre cómo calcular el bit-vector, pero aparece ¿intercambiado? en la fórmula de Calui. Además, qué es un vector de i-nodos, todavía me resulta un misterio.

Sobre lo del tamaño del filesystem... la forma de calcular el tamaño máximo del FS y su resultado está en el primer post que hice. Ahora, si entendí bien, ¿el tamaño real del FS es el menor número de "el tamaño máximo del FS vs. el tamaño del disco"?

Como bien decís, el tamaño REAL del FS es el menor entre el tamaño del disco y el tamaño máximo del FS.

Saludos!

Uh, sí lo de tamaño de FS puede ser así. La verdá que me confunde porque hicimos algún ejercicio durante la cursada que calculábamos todas las estructuras (aclaración: El bit vector es el vector que indica si un bloque está ocupado o no y el vector de i-nodos indica que i-nodos están ocupados).
La proporción del MBR y el Superbloque la encontré en algún lado, la verdad que no me acuerdo dónde, pero dice que el tamaño del MBR es la midad del tamaño del Superblock, y que por defecto tiene 1 bloque asignado el MBR.

Ya que estamos, consulto 2 ejercicio de filesystem mas basico, a ver si me ayudan ? (si, mas facil, pero no me acuerdo nada de este tema )
Son similares al b, pero ninguno aclaro nada asique me quedo medio nebulosa jja


Uno esta resuelto, asique seria la "explicacion" a ver si lo entendi, y el otro a ver si lo resolvi bien

Cita:10. Se dispone de un disco de 700 pistas 200 sectores y 2 platos de capacidad formateado para que trabaje con un sistema de archivos tipo UNIX cuyas características se describen a continuación:

Tamaño de bloque 1kbyte
Tamaño de la dirección de bloque: 64 bits
Número de i-nodos: 700
Campos del i-nodo:
• Atributos del archivo (974bytes)
• 2 punteros directos
• 1 puntero indirecto simple
• 1 puntero indirecto doble
• 1 puntero triple

c. Suponiendo que el i-nodo está en memoria y que los registros de este archivo son de 2k. ¿Cuántos accesos a disco se necesitan para leer los primeros 3000 registros ?

la respuesta es

Cita:3000 registros necesitan 6000 bloques para almacenarlos.

Accesos = 6000+1(simple)+1(doble)+46 (simples del doble)= 6048

Los 6000 son los bloques cuando los lee, lo que me queda duda son las simples, dobles y simples del doble.
Esto quiere decir que cuando se refiere al "inodo esta en memoria" solo estan los punteros directos y el primer puntero de cada indireccion ? Osea, cuando tengo un puntero indirecto, tengo que buscar el sector a disco, y no lo tengo en memoria. Se refiere a eso ?
Pareceria que si, pero de nuevo, son solo suposiciones

Luego, este ejercicio

Cita:8- Se tiene un sistema con ext2 como filesystem, con bloques de 4 KiB y punteros de 8 bytes. El
inodo está conformado con 12 punteros directos, 1 indirecto, 1 indirecto doble y 1 indirecto
triple. Asumiendo que el sector tiene igual tamaño que un bloque, se pide la cantidad de accesos
a disco necesaria para leer:
a) El byte nro 16777227 de un archivo
b) Desde el byte 0 hasta el 250180 de un archivo

a) Lo que hice del punto 1 es: Tener 16777227 bytes equivale a 16 mb + 4 kb (osea leer 16 mb, me deja a 8 bytes, asique tengo que leer el sector siguiente a leer 16 mb)

Haciendo cuentas, con los 12 directos solo llego a cubrir con los directos 48 kb\[(12x4KB)\] , y con el unico puntero indirecto llego a 2 MB (\[1x(\frac{4x1024bytes}{8bytes})^{1}x4x1024bytes=2MB\]).
Con el indirecto doble si llego a los 16 mb ( y paso), por lo que el byte a leer estaría ahi.
Como no se especifica que el inodo este en memoria, lo tengo que leer en disco ?? De esto no estoy seguro. Si esto es asi, y implica una lectura seria:

lectura inodo + primera indireccion doble + indireccion simple del doble + dato = 4 lecturas ?


sobre el:

b) desde 0 a 250180 serían 61.07 bloques, osea, 62 bloques.
Serían leer 62 datos de disco. Ahora, 12 los tengo directos del inodo, y luego los otros salen por indireccion simple (llegaba hasta 2 mb, y esta lectura equivaldria a 248 kb)

Entonces, lo mismo que el punto anterior, el inodo lo tengo que buscar a disco ?
Entonces serian

62 lecturas de bloques + lectura de inodo + lectura de indireccion simple = 64 lecturas ?

confirmenme o corrijanme asi puedo seguir con estos ejercicios sabiendo que lo hago bien y no a ciegas


edit: Otra duda, tengo un ejercicio como el primer posteado, pero no aclara el tamaño del sector de disco (ni dice nada de fisico). Cuando no se da, esta bien asumir que es 512 bytes ? Creí haber leido eso en algun lado pero no lo encuentro.

otra duda, tengo un ejercicio similar al primero posteado (los mismos datos, excepto 700 inodos en vez de 7000, y otras preguntas), y me pide calcular el tamaño de file descriptor ademas del tamaño del disco, pero veo que la forma de calcularlo es igual al del vector de inodos (tamaño de un inodo x cantidad de inodos)

La guia es una de esas de casas + de luca

Estara mal el enunciado ? Tenia entendido que el file descriptor era un handler para manejar un archivo (seria un inodo a lo sumo).
Por que lo multiplicaria por los 700 ?

Cita:edit: Otra duda, tengo un ejercicio como el primer posteado, pero no aclara el tamaño del sector de disco (ni dice nada de fisico). Cuando no se da, esta bien asumir que es 512 bytes ? Creí haber leido eso en algun lado pero no lo encuentro.

esta ya la encontre, si, son 512 bytes si no aclara

http://www.campusvirtual.frba.utn.edu.ar...php?d=3675

---

Cita:otra duda, tengo un ejercicio similar al primero posteado (los mismos datos, excepto 700 inodos en vez de 7000, y otras preguntas), y me pide calcular el tamaño de file descriptor ademas del tamaño del disco, pero veo que la forma de calcularlo es igual al del vector de inodos (tamaño de un inodo x cantidad de inodos)

La guia es una de esas de casas + de luca

Estara mal el enunciado ? Tenia entendido que el file descriptor era un handler para manejar un archivo (seria un inodo a lo sumo).
Por que lo multiplicaria por los 700 ?

aca esta el enunciado

http://pastebin.com/NS6ZkfAP

adriano me aclaro que esta mal la pregunta, buenisimo. Un tema menos ! Gracias adro !!

Holis, te contesto porque me lo pediste pero veo que ya estas en buen camino.

Si te dice que el inodo esta en memoria entonces lo que tenes son los punteros, si alguno es indirecto entonces significa que ese puntero apunta a un bloque de punteros (un indice) y por ende tenes que ir a buscar ese bloque para poder leer el puntero directo al bloque de datos (si es doblemente indirecto, entonces es un bloque de punteros a bloques de punteros a bloques de datos y asi sucesivamente)

Si no te dice nada, aclara que consideras que el inodo no esta en memoria y sumale un acceso a disco y listo.

Después el ejercicio de leer del byte 0 al 250180 esta perfecto. Lo unico que tenes que tener guarda es que si te hubiese caido en uno de indireccion doble o triple, te tenes que poner a calcular cuantos bloques de indireccion intermedios tenes que leer.

La otra pregunta de los 700 o 7000 inodos, te preguntaba dos cosas, una era el tamaño del file descriptor que si consideras un inodo tenes que calcular el tamaño del inodo, que es la info administrativa mas lo que ocupan los punteros del inodo. Y despues decis que tambien te pide el tamaño del disco, y ahi lo que podes hacer es saber cuanto ocupa en base a cuanto puede direccionar los 7000 inodos, entonces te fijas cuantos bloques puede direccionar cada inodo, te fijas cuantos bytes equivalen y lo multiplicas por 7000.

Y mirando el enunciado como que lo que preguntaba no era eltamaño del file descriptor sino por ahi cuanto ocupaban todos los inodos enel disco o algo asi....

Suerte!