Donar $20 Donar $50 Donar $100 Donar mensualmente
 


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
Final SO 10/12/2013 - Ejer FileSystem
Autor Mensaje
Andre Sin conexión
Empleado de Fotocopiadora
Sin estado :(
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 26
Agradecimientos dados: 4
Agradecimientos: 5 en 2 posts
Registro en: Mar 2011
Mensaje: #1
Final SO 10/12/2013 - Ejer FileSystem Finales Sistemas Operativos
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)
09-02-2014 15:35
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Jumanji Sin conexión
Empleado de Fotocopiadora
Sin estado :(
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 26
Agradecimientos dados: 0
Agradecimientos: 4 en 2 posts
Registro en: Feb 2011
Mensaje: #2
RE: Final SO 10/12/2013 - Ejer FileSystem
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!
(Este mensaje fue modificado por última vez en: 09-02-2014 20:46 por Jumanji.)
09-02-2014 20:38
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Andre Sin conexión
Empleado de Fotocopiadora
Sin estado :(
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 26
Agradecimientos dados: 4
Agradecimientos: 5 en 2 posts
Registro en: Mar 2011
Mensaje: #3
RE: Final SO 10/12/2013 - Ejer FileSystem
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?!!
09-02-2014 22:25
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Jumanji Sin conexión
Empleado de Fotocopiadora
Sin estado :(
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 26
Agradecimientos dados: 0
Agradecimientos: 4 en 2 posts
Registro en: Feb 2011
Mensaje: #4
RE: Final SO 10/12/2013 - Ejer FileSystem
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."
10-02-2014 16:41
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
NaiaraAcosta Sin conexión
Militante
Sueña...
***

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 99
Agradecimientos dados: 83
Agradecimientos: 39 en 18 posts
Registro en: May 2012
Mensaje: #5
RE: Final SO 10/12/2013 - Ejer FileSystem
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!!
28-02-2015 12:32
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
norchow Sin conexión
Empleado del buffet
Sin estado :(
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 23
Agradecimientos dados: 22
Agradecimientos: 12 en 9 posts
Registro en: Jul 2013
Mensaje: #6
RE: Final SO 10/12/2013 - Ejer FileSystem
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!
01-03-2015 20:33
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] norchow recibio 1 Gracias por este post
NaiaraAcosta (01-03-2015)
Buscar en el tema
Enviar respuesta 




Usuario(s) navegando en este tema: 1 invitado(s)



    This forum uses Lukasz Tkacz MyBB addons.