Hola!! por favor alguien hizo o puede ver si es correcta esta resolución por favor? anoto con rojo una duda ahi!!
Gracias!

Un file system de tipo EXT2 maneja punteros de 32 bits, bloques de 4 KiB y la conformación de su inodo es de 10 punteros directos, 1 indirecto simple, 1 indirecto doble y 1 indirecto triple.
En dicho file system, bajo la ruta /root/secret, se aloja el archivo “Resumen.pdf” de 10 MiB, el cual se lee y comprime encriptado a la mitad de su tamaño, guardándose en el mismo directorio como “Resumen.tar.gz”. Luego, en el mismo directorio se crea un hard link a “Resumen.pdf”, y un symbolic link a “Resumen.tar.gz”.

a) Indique cuántos accesos a disco fueron necesarios para realizar la lectura del archivo original.
b) Grafique el contenido del archivo /root/secret, agregando por cada archivo del directorio la cantidad de bloques de datos alocados.

Nota: El disco está formado por sectores de 1024 bytes, y el n° de inodo de “Resumen.pdf” es 10.


Pto a)

Para leer los 10 MB necesito
10 lecturas (directos) + 1025 ( indirecto simple son 1024 + 1 por el bloque de punteros) + 1529 (1526 bloques de datos + 3 por los bloques de puntero) = 2564 lecturas de bloques lógicos

Como dice que el disco tiene sectores de 1024 entonces 1 bloque contiene 4 sectores
Entonces hago
2564 * 4 = 10256 accesos a disco

Pto b)

Duda: la cantidad de bloques que ocupa el softlink es 0 cero ?

Si es asi me queda

Nombre cant bloques inodo
Resumen.pdf 2560 10
Resumen.tar.gzz 1280 12 (supongo este nro de inodo)
hlResumen.pdf 2560 10
slResumen.tar.gz 0 13 (supongo este nro de inodo)

Hola, tengo entendido que el softlink ( symbolic link) ocupa un bloque para guardarse la ruta de aquel archivo al cual quiere referenciar.

Con respecto al ejercicio a mi me quedo igual a vos, salvo por el bloque que ocuparía el softlink, que vos pusiste en el punto B en 0.

Saludos!

yo tenia dudas si ocupaba 1 o 0

pero haciendo en linux con el comando du sobre un soft link, me mostro 0

ahora la duda es donde guarda el path?!!

Creo que encontré la respuesta: depende de la forma que se implementen los soft link, si es "fast" los bloques de datos serían 0, si es "slow" sería 1 tengo entendido en base a lo siguiente:

"Fast symbolic links

When the pathname contains up to 64 bytes, it can be saved directly in the inode, on the i_block[0] - i_block[15] variables, since those are not needed in that case. This is called fast symbolic link. It is fast because the pathname resolution can be done using the inode itself, without accessing additional blocks. It is also economical, since it allocates only an inode. The length of the pathname is stored in the i_size variable.

Slow symbolic links

Starting from 65 bytes, additional block is allocated (by the use of i_block[0]) and the pathname is stored in it. It is called slow because the kernel needs to read additional block to resolve the pathname. The length is again saved in i_size."

Bueno completo los V o F para compararlos

1. Falso. No existe segmentacion por Demanda
2. Verdadero. Son las interrupciones de reloj las que activan al dispatcher
3. Verdadero?
4.Falso. Todo lo que dice es correcto pero de disco no trae la dirección de la pagina, lo que trae es la pagina a memoria
5.Verdadero, porque si se esta ejecutando una region critica (con semaforos mutex) no se va poder cortar la ejecucion de la region critica ya que los semaforos desactivan las interrupciones, como la de reloj por lo que quantum podria llegar a durar mas.

Si tienen algo que corregir o aportar es bienvenido!!

Buenas,

Con respecto al 3) del VoF, para mí es Falso. En los inodos (que son los FCB de los FS de tipo EXT) entiendo que no está la ruta completa al archivo.
De hecho, no tiene ningún dato referente a la ubicación. Contiene el dueño, el tamaño, cant de hard links, fechas de uso/creación y punteros a bloques de datos/punteros (puede que me olvide de algún campo).

Me sonó raro por el tema de cómo harías los hard links.. el mismo inodo debería tener todas las ubicaciones de todos los hard links (y que yo sepa solo guarda la cantidad)

Saludos!