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
[Sistemas Operativos] VoF de Finales (FileSystem)
Autor Mensaje
Alejandro Sin conexión
Militante
nada
***

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 84
Agradecimientos dados: 5
Agradecimientos: 224 en 21 posts
Registro en: Apr 2008
Mensaje: #1
[Sistemas Operativos] VoF de Finales (FileSystem) Finales Sistemas Operativos
Aporto VoF de finales resueltos, solo de FileSystem, algunos resueltos por mi y otros los encontré resueltos, la idea es debatir cuales estan mal.

Hay distintos tipos de File System, pero todos impiden crear el Directorio Raíz de un disco lógico mediante la operación crear directorio.

Verdadero, El directorio raiz viene creado por defecto y no se puede borrar, es el único directorio que no está contenido dentro de otro directorio.

En un sistema multiprogramado, alcanza con tener en memoria una tabla global de archivos abiertos para el manejo de archivos de parte de los procesos.
Falso, aparte cada proceso mantiene una tabla local de archivos abiertos.

Dado un SO que controla dos File Systems diferentes, el espacio libre de los mismos es manejado de igual forma para ambos.
Falso, cada File System tiene su propia forma de manejar el espacio libre.

Los archivos con organización indexada cuentan con un único índice formado por la combinación de todos los campos que maximiza la velocidad de búsqueda dentro del archivo.
Falso ya que es necesario tener un índice por cada campo sobre el que se puedan hacer búsquedas.

La técnica ¨Bloqueo de Registro¨ en un File System no interactúa con el hardware de Memoria Virtual cuando esta es usada
Falso. “La técnica de Bloques y Registros” utilizada podría interaccionar con el HW de MV, si ésta se utilizara.” [Stallings, 5ª ed. Esp., Pg. 566].

Cuando se abre por primera vez un archivo, ¿el sistema de gestión de archivos carga en memoria el descriptor de archivos almacenado en disco, correspondiente a dicho archivo?
Verdadero. El descriptor guarda información acerca del archivo y es necesaria para su gestión. Cuando se abre por primera vez un archivo, se busca el nombre en la estructura de directorios para encontrar el nombre del archivo (parte de la estructura de dir suele estar cacheada para agilizar). Se carga el FCB (File Control Block) en la tabla global de archivos abiertos, y se crea una entrada en la tabla de archivos abiertos del proceso (éste es el descriptor de archivo/ file handle/ file descriptor), con un puntero a la entrada en la tabla global de archivos abiertos.

Para archivos de tamaño grande es mejor, por cuestiones de desempeños, trabajar con estructuras tipo i-nodos.
Verdadero. El uso de punteros y distintos niveles de indirección permiten manejar archivos grandes de manera eficiente.

La asignación de bloques en un FS elimina la fragmentación interna.
Falso. Elimina la fragmentación externa [Stallings, 5ª ed. Esp., Pg. 571].

En un filesystem la organización más compleja es la denominada pila.
Falso. La pila es la forma de organización de archivos más simple. Los datos se recolectan en el orden en que llegan. Cada registro consiste en una ráfaga de datos. El propósito de la pila es simplemente acumular la masa de datos y guardarlo.

La estructura de archivo llamada Archivo Secuencial (Sequential File) soluciona una de las deficiencias de la estructura de Pila al permitir Acceso Aleatorio.

Falso. No es posible el acceso aleatorio en archivos secuenciales, las búsquedas se realizan en forma secuencial.

En un filesystem basado en la técnica de Journaling, como por ejemplo NTFS o EXT3, es necesario hacer un bloqueo de la estructura de datos con el objetivo de garantizar la atomicidad de la operación de modificación.
V. El procedimiento de journaling es básicamente el siguiente:
1.Se bloquean las estructuras de datos afectadas por la transacción para que ningún otro proceso pueda modificarlas mientras dura la transacción.
2.Se reserva un recurso para almacenar el journal. Por lo general suelen ser unos bloques de disco, de modo que si el sistema se para de forma abrupta (corte eléctrico, avería, fallo delsistema operativo...) el journal siga disponible una vez reiniciado el sistema.
3.Se efectúan una a una las modificaciones en la estructura de datos. Para cada una: Se apunta en el journal como deshacer la modificación y se asegura de que esta información se escribe físicamente en el disco. Se realiza la modificación.
4.Si en cualquier momento se quiere cancelar la transacción se deshacen los cambios uno a uno leyéndolos y borrándolos del journal.
5.Si todo ha ido bien, se borra el journal y se desbloquean las estructuras de datos afectadas.

Los archivos hasheados o directos, hacen uso de la capacidad del disco de acceder directamente a un bloque: no existe el concepto de orden secuencial.
Verdadero. [Stallings, 5ª ed. Esp., Pg. 558].

La cantidad de memoria necesaria para almacenar el mapa de bits para la administración de bloques libres será mayor o menor para un mismo disco según varíe el tamaño de un bloque.
Verdadero, con un bit se sabe si un bloque esta libreo o ocupado, por lo tanto se necesitara más espacio si la cantidad de bloques es mayor. tamaño del disco en bytes / (cantidad de bloques * 8)

En un file system la organización más compleja es la denominada pila.
Falso, es la más simple.

La organización de archivos más sencilla que existe se denomina Pila. Una de las razones de su sencillez tiene relación con la posibilidad de acceder directamente a cualquiera de sus registros. St 5 ed español pag 555 ingles 542
Falso, no se puede acceder directamente a cualquiera de sus registros, hay que hacer una búsqueda exhaustiva.

Si se tiene un FileSystem que utiliza asignación encadenada de espacio en disco con un tamaño de bloques de 1024 bytes, punteros de 4 bytes y un archivo de 1 MB, entonces 1024 son los bloques que ocupa dicho archivo.
Falso, porque cada bloque tiene un puntero al siguiente bloque por lo que solo podría almacenar 1020 bytes por bloque, la excepción es que se utilice FAT.

Con una FAT de 10000 entradas, un archivo puede poseer más de 10010 bloques de disco.
Falso, se puede direccionar hasta 10000 bloques.

En un File System basado en FAT el tamaño máximo de un archivo está definido por el tamaño de la partición.
Verdadero, porque el tamaño de la partición no incluye el tamaño de la FAT.

Sistemas FAT necesitan el MBR, la lista enlazada de bloques del disco, la 2da lista, bit-vector, el superbloque y una estructura de directorios para funcionar.
Falso. El superbloque está presente en los sistemas de archivos de UNIX. NO en FAT. El superbloque contiene atributos e info sobre el sistema de archivos, tal como el tamaño de la partición y el tamaño de la tabla de Inodos.

El tamaño de un file system tipo UNIX depende del tamaño del bloque, del tamaño del puntero y de la cantidad de punteros disponibles del i-nodo.
Falso, no depende de la cantidad de punteros disponibles del i-nodo.
Tamaño máximo teórico del filesystem = * TB
n: tamaño de puntero
TB: tamaño de bloque

La lista de i-nodos de un sistema de archivos tipo UNIX crece a medida que se crean nuevos archivos.
Falso, el espacio que ocupa la tabla de inodos es fijo.

El tamaño máximo del file system de tipo UNIX está determinado únicamente por el tamaño del puntero y por la cantidad de punteros directos e indirectos que posee el I-NODO.
Falso, el tamaño del file system está determinado por el tamaño del bloque y la cantidad de bloques que se le asigne.

Los archivos implementados bajo la estructura I-Nodos poseen fragmentación interna y externa, debido a esto deben desfragmentarse los discos esporádicamente, para obtener espacio libre contiguo.
Falso. Los archivos implementados con I-Nodos no presentan fragmentación externa ya que no necesitan estrictamente espacio contiguo para su almacenamiento.

Como en todo FileSystem basado en i-nodos, en ext2, el superblock es único y no se repite.
Falso, puede haber copias del superbloque en determinados Grupos de Bloques. (concepto de Sparse Superblock)

En archivos extremadamente largos es más rápido el acceso a los últimos bytes del archivo si el sistema se basa en inodos que si se basa en FAT.
Verdadero, las indirecciones provistas por los I-Nodos permiten un acceso más rápido al bloque buscado. En fat como la asignación de espacio del archivo es enlazada se deben leer los bloques hasta el que contiene el byte.

En filesystems de tipo UNIX, siempre es conveniente utilizar “hard links” por sobre “symbolic links”.
Falso, depende el caso, una desventaja del hard link es que si quiero eliminar el archivo original para hacer espacio en el disco, lo tengo que eliminar desde todas sus ubicaciones, Los enlaces simbólicos se pueden hacer con ficheros y directorios mientras que los duros solo entre ficheros. Los enlaces simbólicos se pueden hacer entre distintos sistemas de ficheros, los duros no.

Si tenemos 2 directorios que contienen enlaces duros a un mismo archivo entonces debemos tener, en los dos i-nodos, el contador de enlaces en 2(dos).
Falso, en el inodo del archivo debería tener el contador de enlaces en 2.

Los enlaces duros permiten que un archivo de datos pueda ser accedido desde cualquier directorio del disco.
Falso. Los enlaces duros permiten que un mismo archivo tenga más de una referencia, al mismo espacio físico de datos.

Un archivo de tipo Soft-Link es un tipo de archivo especial que no posee la localización física del archivo
Falso, contiene una referencia a la ruta donde se encuentra el archivo.

A diferencia de los hard links, los symbolic links pueden pertenecer a diferentes file system.
Verdadero, los Hard links sólo pueden pertenecer a un mismo file-system.

En el filesystem FAT, se podría simular un “hard link” similar al de UNIX si se creara una entrada de directorio apuntando al mismo número de cluster que otro archivo ya existente, sin que eso ocasione otros problemas con el manejo de atributos de los archivos.
Falso, el problema sería que no se llevaría una cuenta de los enlaces.

En el enlace simbólico de archivos UNIX, dos nombres apuntan al mismo i-nodo.
Falso, el enlace simbólico apunta a un inodo distinto que tiene una referencia a la ruta del archivo al cual se quiere linkear.

La razón por la que los i-nodos permiten que el File System posea una estructura de grafo acíclico es debido a la posibilidad de utilizar HARDLINK , cosa que no es posible con la estructura de un File System de tipo FAT.
Verdadero porque el inodo lleva un atributo para contar las referencias que tiene y hacer posible el uso de hard links, la estructura es de grafo acíclico porque no se permiten hard links a directorios.

El número de enlaces de un archivo en UNIX se almacena en la entrada de directorio correspondiente.
Falso, se almacena como atributo en el inodo.

Sólo cuando se elimine el último symbolic link de un archivo, los bloques ocupados por el mismo serán considerados como disponibles.
Falso, si se elimina un symbolic link no se elimina el archivo original, la frase sería válida si fuera hard links en vez de symbolic links.
(Este mensaje fue modificado por última vez en: 19-01-2013 15:46 por Alejandro.)
14-01-2013 22:04
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Alejandro recibio 9 Gracias por este post
jimena (15-01-2013), martintama (02-02-2013), Axius (06-03-2013), lucascla (12-07-2013), alan2506 (29-01-2014), H3rnst (07-07-2014), SilvinaG (02-10-2014), drechu (24-07-2015), leandrong (20-02-2016)
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: #2
RE: [Sistemas Operativos] VoF de Finales (FileSystem)
Agrego 2 v/f , por favor me avisan si coincidimos o si hay algo mal? gracias!!

Cuando se abre un archivo se crea en memoria el FCB y los datos que este contiene provienen en parte del I-nodo o del directorio dependiendo del sistema operativo
Verdadero
El FCB se copia en la tabla global de archivos existentes en la memoria.
La tabla global de archivos abiertos almacena los inodos y otra info para archivos y directorios

Cuando se abre un archivo siempre el header se copia en memoria para saber donde comienza el archivo y cuando el proceso lo cierra esta estructura se elimina.
Falso
La tabla de archivos abiertos tiene un contador de aperturas, cada llamada a close, reduce este contador de aperturas y cuando el contador de aperturas alcanza el valor cero, querrá decir que el archivo dejó de usarse y se eliminará de la tabla de archivos abiertos la tabla correspondiente al archivo.

Duda: el header es el FCB? Porque cuando se abre el archivo se copia en memoria el FCB, no encuentro en el libro con el término de header!
25-01-2014 23:26
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Buscar en el tema
Enviar respuesta 




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



    This forum uses Lukasz Tkacz MyBB addons.