Dentro del Sistema de Archivos

Índice
Introducción

Sistemas de archivos

Montaje del sistema de archivos

Particiones y montaje

Uso compartido de archivos

Usuarios múltiples

Sistemas de archivos virtuales

Sistemas de archivos remotos

El modelo cliente-servidor
Sistemas de información distribuidos
Modos de falla

Semántica de consistencia
Semántica UNIX
Semántica de sesión
Semántica de archivos compartidos inmutables

NFS
Descripción
El protocolo de montaje
El protocolo NFS
Traducción de nombre de ruta
Operaciones remotas
Introducción
Como vimos, el sistema de archivos proporciona el mecanismo para el almacenamiento en
línea y el acceso al contenido de los archivos, incluidos los datos y los programas. Este
capítulo se ocupa principalmente de las estructuras internas y las operaciones de los
sistemas de archivos. Exploramos en detalle formas de estructurar el uso de archivos,
asignar espacio de almacenamiento, recuperar espacio liberado, rastrear las ubicaciones de
los datos e interconectar otras partes del sistema operativo con el almacenamiento
secundario.

Objetivos

● Profundizar en los detalles de los sistemas de archivos y su implementación.

● Explore el inicio y el intercambio de archivos.
● Describir sistemas de archivos remotos, usando NFS como ejemplo.

Sistemas de archivos
Ciertamente, ninguna computadora de propósito general almacena un solo archivo. Por lo
general, hay miles, millones e incluso miles de millones de archivos dentro de una
computadora. Los archivos se almacenan en dispositivos de almacenamiento de acceso
aleatorio, incluidas unidades de disco duro, discos ópticos y dispositivos de memoria no
volátil.

Como hemos visto antes, un sistema informático de uso general puede tener varios
dispositivos de almacenamiento, y esos dispositivos se pueden dividir en particiones, que
contienen volúmenes, que a su vez contienen sistemas de archivos. Dependiendo del
administrador de volumen, un volumen también puede abarcar varias particiones. La figura
1 muestra una organización típica de un sistema de archivos.

Los sistemas informáticos también pueden tener un número variable de sistemas de

archivos y los sistemas de archivos pueden ser de diferentes tipos. Por ejemplo, un sistema
Solaris típico puede tener docenas de sistemas de archivos de una docena de tipos
diferentes, como se muestra en la lista de sistemas de archivos en la figura 2.

Consideramos solo los sistemas de archivos de uso general. Sin embargo, vale la pena
señalar que existen muchos sistemas de archivos para propósitos especiales. Considere los
tipos de sistemas de archivos en el ejemplo de Solaris mencionado anteriormente:
 ● tmpfs: un sistema de archivos “temporal” que se crea en la memoria principal volátil
y su contenido se borra si el sistema se reinicia o falla
● objfs: un sistema de archivos “virtual” ( esencialmente una interfaz para el kernel
que parece un sistema de archivos) que brinda a los depuradores acceso a los
símbolos del kernel
● ctfs: un sistema de archivos virtual que mantiene información de "contrato" para
administrar qué procesos se inician cuando el sistema arranca y deben continuar
ejecutándose durante la operación
● lofs: un sistema de archivos de “bucle de retorno” que permite acceder a un sistema
de archivos en lugar de otro
● procfs: un sistema de archivos virtual que presenta información sobre todos los
procesos como un sistema de archivos
● ufs, zfs: sistemas de archivos de uso general

Los sistemas de archivo de computadoras, entonces, pueden ser extensos. Incluso dentro
de un sistema de archivos, es útil separar los archivos en grupos y administrarlos y actuar
sobre ellos. Esta organización implica el uso de directorios

Montaje del sistema de archivos

Al igual que un archivo debe abrirse antes de que pueda usarse, un sistema de archivos
debe montarse antes de que pueda estar disponible para los procesos del sistema. Más
específicamente, la estructura de directorios puede construirse a partir de múltiples
volúmenes que contienen el sistema de archivos, que deben montarse para que estén
disponibles dentro del espacio de nombres del sistema de archivos.

El procedimiento de montaje es sencillo. El sistema operativo recibe el nombre del

dispositivo y el punto de montaje, la ubicación dentro de la estructura de archivos donde se
adjuntará el sistema de archivos. Algunos sistemas operativos requieren que se proporcione
un tipo de sistema de archivos, mientras que otros inspeccionan las estructuras del
dispositivo y determinan el tipo de sistema de archivos. Normalmente, un punto de montaje
es un directorio vacío. Por ejemplo, en un sistema UNIX, un sistema de archivos que
contiene los directorios de inicio de un usuario puede estar montado como /home; luego,
para acceder a la estructura de directorios dentro de ese sistema de archivos, podríamos
preceder los nombres de directorio con /home, como en /home/jane. Montar ese sistema
de archivos en /users daría como resultado el nombre de ruta /users/jane, que
podríamos usar para llegar al mismo directorio.

A continuación, el sistema operativo verifica que el dispositivo contenga un sistema de

archivos válido. Lo hace pidiendo al controlador del dispositivo que lea el directorio del
dispositivo y verificando que el directorio tenga el formato esperado. Finalmente, el sistema
operativo nota en su estructura de directorios que un sistema de archivos está montado en
el punto de montaje especificado. Este esquema permite al sistema operativo atravesar su
estructura de directorios, cambiar entre sistemas de archivos e incluso sistemas de archivos
de diversos tipos, según corresponda.

Para ilustrar el montaje de archivos, considere el sistema de archivos que se muestra en la

figura 3, donde los triángulos representan subárboles de directorios que son de interés. La
figura 3 (a) muestra un sistema de archivos existente, mientras que la figura 3 (b) muestra
un volumen desmontado que reside en /device/dsk. En este punto, solo se puede
acceder a los archivos del sistema de archivos existente. La figura 4 muestra los efectos de
montar el volumen que reside en /device/dsk sobre /users. Si se desmonta el
volumen, el sistema de archivos se restaura a la situación que se muestra en la figura 3.
Los sistemas imponen semánticas para aclarar la funcionalidad. Por ejemplo, un sistema
puede no permitir un montaje sobre un directorio que contiene archivos; o puede hacer que

el sistema de archivos montado esté disponible en ese directorio y ocultar los archivos
existentes del directorio hasta que se desmonte el sistema de archivos, terminando el uso
del sistema de archivos y permitiendo el acceso a los archivos originales en ese directorio.
Como otro ejemplo, un sistema puede permitir que el mismo sistema de archivos se monte
repetidamente, en diferentes puntos de montaje; o puede que solo permita un montaje por
sistema de archivos.

Considere las acciones del sistema operativo macOS. Siempre que el sistema encuentra un
disco por primera vez (ya sea en el momento del arranque o mientras el sistema se está
ejecutando), el sistema operativo macOS busca un sistema de archivos en el dispositivo. Si
encuentra uno, automáticamente monta el sistema de archivos en el directorio /Volumes,
agregando un ícono de carpeta etiquetado con el nombre del sistema de archivos (como
está almacenado en el directorio del dispositivo). A continuación, el usuario puede hacer clic
en el icono y así mostrar el sistema de archivos recién montado.

La familia de sistemas operativos Microsoft Windows mantiene una estructura de directorio

extendida de dos niveles, con dispositivos y volúmenes asignados con letras de unidad.
Cada volumen tiene una estructura de directorio de gráficos general asociada con su letra
de unidad. La ruta a un archivo específico toma la forma de
letra_de_unidad:∖ruta∖a∖archivo. Las versiones más recientes de Windows
permiten montar un sistema de archivos en cualquier lugar del árbol de directorios, tal como
lo hace UNIX. Los sistemas operativos Windows detectan automáticamente todos los
dispositivos y montan todos los sistemas de archivos ubicados en el momento del arranque.
En algunos sistemas, como UNIX, los comandos de montaje son explícitos. Un archivo de
configuración del sistema contiene una lista de dispositivos y puntos de montaje para el
montaje automático en el momento del arranque, pero otros montajes se pueden ejecutar
manualmente.

Particiones y montaje
El diseño de un disco puede tener muchas variaciones, según el sistema operativo y el
software de administración de volumen. Un disco puede dividirse en varias particiones o un
volumen puede abarcar varias particiones en varios discos. El primer diseño se analiza
aquí, mientras que el segundo, se considera más apropiadamente una forma de RAID.

Cada partición puede ser "sin procesar", que no contiene ningún sistema de archivos, o
"cocinada", que contiene un sistema de archivos. El disco sin formato se utiliza donde no
es apropiado ningún sistema de archivos. El espacio de intercambio de UNIX puede usar
una partición sin formato, por ejemplo, ya que usa su propio formato en el disco y no usa un
sistema de archivos. Asimismo, algunas bases de datos utilizan discos sin procesar y
formatean los datos para satisfacer sus necesidades. El disco sin formato también puede
contener la información que necesitan los sistemas RAID de disco, como mapas de bits que
indican qué bloques están reflejados y cuáles han cambiado y deben reflejarse. De manera
similar, el disco sin formato puede contener una base de datos en miniatura que contenga
información de configuración RAID, como qué discos son miembros de cada conjunto RAID.

Si una partición contiene un sistema de archivos que es de arranque, que tiene un sistema
operativo correctamente instalado y configurado, entonces la partición también necesita
información de arranque. Esta información tiene su propio formato, porque en el momento
del arranque el sistema no tiene cargado el código del sistema de archivos y, por lo tanto,
no puede interpretar el formato del sistema de archivos. Más bien, la información de
arranque suele ser una serie secuencial de bloques cargados como una imagen en la
memoria. La ejecución de la imagen comienza en una ubicación predefinida, como el primer
byte. Esta imagen, el cargador de arranque, a su vez, sabe lo suficiente sobre la estructura
del sistema de archivos para poder encontrar y cargar el kernel e iniciar su ejecución.

El cargador de arranque puede contener más que las instrucciones para arrancar un
sistema operativo específico. Por ejemplo, muchos sistemas se pueden arrancar de forma
dual, lo que nos permite instalar varios sistemas operativos en un solo sistema. ¿Cómo
sabe el sistema cuál arrancar? Un cargador de arranque que comprenda varios sistemas de
archivos y varios sistemas operativos puede ocupar el espacio de arranque. Una vez
cargado, puede arrancar uno de los sistemas operativos disponibles en la unidad. La unidad
puede tener varias particiones, cada una de las cuales contiene un tipo diferente de sistema
de archivos y un sistema operativo diferente. Tenga en cuenta que si el cargador de
arranque no comprende un formato de sistema de archivos en particular, un sistema
operativo almacenado en ese sistema de archivos no es de arranque. Esta es una de las
razones por las que solo algunos sistemas de archivos son compatibles como sistemas de
archivos raíz para cualquier sistema operativo determinado.

La partición raíz seleccionada por el cargador de arranque, que contiene el kernel del
sistema operativo y, a veces, otros archivos del sistema, se monta en el momento del
arranque. Otros volúmenes se pueden montar automáticamente en el arranque o
manualmente más tarde, según el sistema operativo. Como parte de una operación de
montaje exitosa, el sistema operativo verifica que el dispositivo contenga un sistema de
archivos válido. Lo hace pidiendo al controlador del dispositivo que lea el directorio del
dispositivo y verificando que el directorio tenga el formato esperado. Si el formato no es
válido, se debe verificar la consistencia de la partición y posiblemente corregirla, ya sea con
o sin la intervención del usuario. Finalmente, el sistema operativo anota en su tabla de
montaje en memoria que un sistema de archivos está montado, junto con el tipo de sistema
de archivos. Los detalles de esta función dependen del sistema operativo.

Los sistemas basados ​en Microsoft Windows montan cada volumen en un espacio de
nombre separado, indicado por una letra y dos puntos, como se mencionó anteriormente.
Para registrar que un sistema de archivos está montado en F:, por ejemplo, el sistema
operativo coloca un puntero al sistema de archivos en un campo de la estructura del
dispositivo correspondiente a F:. Cuando un proceso especifica la letra del controlador, el
sistema operativo encuentra el puntero del sistema de archivos apropiado y atraviesa las
estructuras de directorio en ese dispositivo para encontrar el archivo o directorio
especificado. Las versiones posteriores de Windows pueden montar un sistema de archivos
en cualquier punto dentro de la estructura de directorios existente.

En UNIX, los sistemas de archivos se pueden montar en cualquier directorio. El montaje se

implementa estableciendo una bandera en la copia en memoria del inodo para ese
directorio. La bandera indica que el directorio es un punto de montaje. Luego, un campo
apunta a una entrada en la tabla de montaje, que indica qué dispositivo está montado allí.
La entrada de la tabla de montaje contiene un puntero al superbloque del sistema de
archivos en ese dispositivo. Este esquema permite que el sistema operativo atraviese su
estructura de directorios, cambiando sin problemas entre sistemas de archivos de diferentes
tipos.
Uso compartido de archivos
La capacidad de compartir archivos es muy deseable para los usuarios que desean
colaborar y reducir el esfuerzo requerido para lograr un objetivo informático. Por lo tanto, los
sistemas operativos orientados al usuario deben adaptarse a la necesidad de compartir
archivos a pesar de las dificultades inherentes.

En esta sección, examinamos más aspectos del intercambio de archivos. Comenzamos

discutiendo los problemas generales que surgen cuando varios usuarios comparten
archivos. Una vez que se permite que varios usuarios compartan archivos, el desafío es
extender el uso compartido a múltiples sistemas de archivos, incluidos los sistemas de
archivos remotos; también discutimos ese desafío. Finalmente, consideramos qué hacer
con las acciones en conflicto que ocurren en archivos compartidos. Por ejemplo, si varios
usuarios escriben en un archivo, ¿debería permitirse que se produzcan todas las escrituras
o el sistema operativo debería proteger las acciones de los usuarios entre sí?

Usuarios múltiples
Cuando un sistema operativo tiene capacidad para varios usuarios, los problemas de uso
compartido de archivos, nombres de archivos y protección de archivos se vuelven
preeminentes. Dada una estructura de directorio que permite que los usuarios compartan
archivos, el sistema debe mediar en el intercambio de archivos. El sistema puede permitir
que un usuario acceda a los archivos de otros usuarios de forma predeterminada o requerir
que un usuario otorgue específicamente acceso a los archivos.

Para implementar el uso compartido y la protección, el sistema debe mantener más

atributos de archivos y directorios de los que se necesitan en un sistema de un solo usuario.
Aunque se han adoptado muchos enfoques para cumplir con este requisito, la mayoría de
los sistemas han evolucionado para utilizar los conceptos de propietario (o usuario) de
archivo (o directorio) y grupo. El propietario es el usuario que puede cambiar los atributos y
otorgar acceso y que tiene más control sobre el archivo. El atributo de grupo define un
subconjunto de usuarios que pueden compartir el acceso al archivo. Por ejemplo, el
propietario de un archivo en un sistema UNIX puede ejecutar todas las operaciones en un
archivo, mientras que los miembros del grupo del archivo pueden ejecutar un subconjunto
de esas operaciones y todos los demás usuarios pueden ejecutar otro subconjunto de
operaciones. El propietario del archivo puede definir exactamente qué operaciones pueden
ejecutar los miembros del grupo y otros usuarios.

Los ID de propietario y grupo de un archivo (o directorio) determinado se almacenan con los

otros atributos del archivo. Cuando un usuario solicita una operación en un archivo, el ID de
usuario se puede comparar con el atributo de propietario para determinar si el usuario
solicitante es el propietario del archivo. Asimismo, se pueden comparar los ID de grupo. El
resultado indica qué permisos son aplicables. Luego, el sistema aplica esos permisos a la
operación solicitada y los permite o niega.

Muchos sistemas tienen varios sistemas de archivos locales, incluidos los volúmenes de un
solo disco o varios volúmenes en varios discos conectados. En estos casos, la verificación
de ID y la coincidencia de permisos son sencillas, una vez que se montan los sistemas de
archivos. Pero considere un disco externo que se pueda mover entre sistemas. ¿Qué pasa
si las ID de los sistemas son diferentes? Se debe tener cuidado para estar seguro de que
Ds coinciden entre sistemas cuando los dispositivos se mueven entre ellos o cuando la
propiedad del archivo se restablece cuando ocurre tal movimiento. (Por ejemplo, podemos
crear una nueva ID de usuario y configurar todos los archivos en el disco portátil con esa ID,
para asegurarnos de que ningún archivo sea accesible accidentalmente para los usuarios
existentes).

Sistemas de archivos virtuales

Como hemos visto, los sistemas operativos modernos deben admitir simultáneamente
varios tipos de sistemas de archivos. Pero, ¿cómo permite un sistema operativo que se
integren varios tipos de sistemas de archivos en una estructura de directorios? ¿Y cómo
pueden los usuarios moverse sin problemas entre los tipos de sistemas de archivos
mientras navegan por el espacio del sistema de archivos? Ahora discutimos algunos de
estos detalles de implementación.

Un método obvio pero subóptimo de implementar múltiples tipos de sistemas de archivos es

escribir rutinas de directorio y archivo para cada tipo. Sin embargo, en su lugar, la mayoría
de los sistemas operativos, incluido UNIX, utilizan técnicas orientadas a objetos para
simplificar, organizar y modularizar la implementación. El uso de estos métodos permite
implementar tipos de sistemas de archivos muy diferentes dentro de la misma estructura,
incluidos los sistemas de archivos de red, como NFS. Los usuarios pueden acceder a
archivos contenidos en múltiples sistemas de archivos en la unidad local o incluso en
sistemas de archivos disponibles en la red.

Se utilizan estructuras y procedimientos de datos para aislar la funcionalidad básica de

llamada al sistema de los detalles de implementación. Por lo tanto, la implementación del
sistema de archivos consta de tres capas principales, como se muestra esquemáticamente
en la figura 5. La primera capa es la interfaz del sistema de archivos, basada en las
llamadas open(), read(), write() y close() y en los descriptores de archivos.
La segunda capa se denomina capa de sistema de archivos virtual (VFS). La capa VFS
tiene dos funciones importantes:

1. Separa las operaciones genéricas del sistema de archivos de su implementación

mediante la definición de una interfaz VFS limpia. Varias implementaciones para la
interfaz VFS pueden coexistir en la misma máquina, lo que permite un acceso
transparente a diferentes tipos de sistemas de archivos montados localmente.
2. Proporciona un mecanismo para representar de forma única un archivo en una red.
El VFS se basa en una estructura de representación de archivos, denominada
vnode, que contiene un designador numérico para un archivo único en toda la red.
(Los inodos de UNIX son únicos dentro de un único sistema de archivos). Esta
singularidad en toda la red es necesaria para admitir sistemas de archivos de red. El
kernel mantiene una estructura de vnode para cada nodo activo (archivo o
directorio).

Por lo tanto, el VFS distingue los archivos locales de los remotos, y los archivos locales se
distinguen aún más según sus tipos de sistema de archivos.

El VFS activa operaciones específicas del sistema de archivos para manejar solicitudes
locales de acuerdo con sus tipos de sistema de archivos y llama a los procedimientos de
protocolo NFS (u otros procedimientos de protocolo para otros sistemas de archivos de red)
para solicitudes remotas. Los identificadores de archivo se construyen a partir de los vnodes
relevantes y se pasan como argumentos a estos procedimientos. La capa que implementa
el tipo de sistema de archivos o el protocolo del sistema de archivos remoto es la tercera
capa de la arquitectura.

Examinemos brevemente la arquitectura VFS en Linux. Los cuatro tipos de objetos

principales definidos por Linux VFS son:
 ● El objeto inodo, que representa un archivo individual
● El objeto file, que representa un archivo abierto
● El objeto superbloque, que representa un sistema de archivos completo
● El objeto dentry, que representa una entrada de directorio individual

Para cada uno de estos cuatro tipos de objetos, el VFS define un conjunto de
operaciones que pueden implementarse. Cada objeto de uno de estos tipos contiene un
puntero a una tabla de funciones. La tabla de funciones enumera las direcciones de las
funciones reales que implementan las operaciones definidas para ese objeto en
particular. Por ejemplo, una API abreviada para algunas de las operaciones del objeto
de archivo incluye:

● int open (...): Abre un archivo.

● int close (...): Cierra un archivo ya abierto.
● ssize_t read (...): Lee de un archivo.
● ssize_t write (...): Escribe en un archivo.
● int mmap (...): Mapa de memoria de un archivo.

Se requiere una implementación del objeto de archivo para un tipo de archivo específico
para implementar cada función especificada en la definición del objeto de archivo. (La
definición completa del objeto de archivo se especifica en las operaciones de archivo de
estructura de archivo, que se encuentra en el archivo /usr/include/linux/fs.h).

Por lo tanto, la capa de software VFS puede realizar una operación en uno de estos
objetos llamando a la función adecuada desde la tabla de funciones del objeto, sin tener
que saber de antemano exactamente con qué tipo de objeto se trata. El VFS no sabe, ni
le importa, si un inodo representa un archivo de disco, un archivo de directorio o un
archivo remoto. La función apropiada para la operación read() de ese archivo siempre
estará en el mismo lugar en su tabla de funciones, y la capa de software VFS llamará a
esa función sin importar cómo se leen realmente los datos.

Sistemas de archivos remotos

Con la llegada de las redes, la comunicación entre computadoras remotas se hizo posible.
La creación de redes permite compartir recursos distribuidos en un campus o incluso en
todo el mundo. Un recurso obvio para compartir son los datos en forma de archivos.

A través de la evolución de la tecnología de archivos y redes, los métodos de intercambio

de archivos remotos han cambiado. El primer método implementado implica la transferencia
manual de archivos entre máquinas a través de programas como ftp. El segundo método
principal utiliza un sistema de archivos distribuido (DFS), en el que los directorios
remotos son visibles desde una máquina local. De alguna manera, el tercer método, la
World Wide Web, es una reversión al primero. Se necesita un navegador para obtener
acceso a los archivos remotos, y se utilizan operaciones separadas (esencialmente un
contenedor para ftp) para transferir archivos. Cada vez más, la computación en la nube
también se utiliza para compartir archivos.
ftp se utiliza tanto para el acceso anónimo como para el autenticado. El acceso anónimo
permite a un usuario transferir archivos sin tener una cuenta en el sistema remoto. La World
Wide Web utiliza el intercambio de archivos anónimo casi exclusivamente. DFS implica una
integración mucho más estrecha entre la máquina que accede a los archivos remotos y la
máquina que proporciona los archivos. Esta integración agrega complejidad, como
describimos en esta sección.

El modelo cliente-servidor
Los sistemas de archivos remotos permiten que una computadora monte uno o más
sistemas de archivos desde una o más máquinas remotas. En este caso, la máquina que
contiene los archivos es el servidor y la máquina que busca acceso a los archivos es el
cliente. La relación cliente-servidor es común en las máquinas en red. Generalmente, el
servidor declara que un recurso está disponible para los clientes y especifica exactamente
qué recurso (en este caso, qué archivos) y exactamente qué clientes. Un servidor puede
servir a varios clientes y un cliente puede utilizar varios servidores, según los detalles de
implementación de una instalación cliente-servidor determinada.

El servidor generalmente especifica los archivos disponibles a nivel de volumen o directorio.

La identificación del cliente es más difícil. Un cliente puede especificarse mediante un
nombre de red u otro identificador, como una dirección IP, pero estos pueden ser
falsificados o imitados. Como resultado de la suplantación de identidad, se podría permitir
el acceso al servidor a un cliente no autorizado. Las soluciones más seguras incluyen la
autenticación segura del cliente mediante claves cifradas. Desafortunadamente, la
seguridad conlleva muchos desafíos, incluida la garantía de la compatibilidad del cliente y el
servidor (deben usar los mismos algoritmos de cifrado) y la seguridad de los intercambios
de claves (las claves interceptadas podrían permitir nuevamente el acceso no autorizado).
Debido a la dificultad de resolver estos problemas, los métodos de autenticación inseguros
son los más utilizados.

En el caso de UNIX y su sistema de archivos de red (NFS), la autenticación se realiza a

través de la información de red del cliente, de forma predeterminada. En este esquema, las
identificaciones del usuario en el cliente y el servidor deben coincidir. De lo contrario, el
servidor no podrá determinar los derechos de acceso a los archivos. Considere el ejemplo
de un usuario que tiene un ID de 1000 en el cliente y 2000 en el servidor. Una solicitud del
cliente al servidor para un archivo específico no se manejará adecuadamente, ya que el
servidor determinará si el usuario 1000 tiene acceso al archivo en lugar de basar la
determinación en el ID de usuario real de 2000. Por lo tanto, el acceso se otorga o deniega
basado en información de autenticación incorrecta. El servidor debe confiar en que el cliente
presente el ID de usuario correcto. Tenga en cuenta que los protocolos NFS permiten
muchas relaciones. Es decir, muchos servidores pueden proporcionar archivos a muchos
clientes. De hecho, una máquina determinada puede ser tanto un servidor para algunos
clientes NFS como un cliente de otros servidores NFS.

Una vez que se monta el sistema de archivos remoto, las solicitudes de operación de
archivos se envían en nombre del usuario a través de la red al servidor a través del
protocolo DFS. Normalmente, se envía una solicitud de apertura de archivo junto con el ID
del usuario solicitante. A continuación, el servidor aplica las comprobaciones de acceso
estándar para determinar si el usuario tiene credenciales para acceder al archivo en el
modo solicitado. La solicitud se permite o se niega. Si está permitido, se devuelve un
identificador de archivo a la aplicación cliente y la aplicación puede realizar operaciones de
lectura, escritura y otras operaciones en el archivo. El cliente cierra el archivo cuando se
completa el acceso. El sistema operativo puede aplicar una semántica similar a la del
montaje de un sistema de archivos local o puede utilizar una semántica diferente.

Sistemas de información distribuidos

Para facilitar el manejo de los sistemas cliente-servidor, los sistemas de información
distribuidos, también conocidos como servicios de nombres distribuidos, brindan
acceso unificado a la información necesaria para la computación remota. El sistema de
nombres de dominio (DNS) proporciona traducciones de nombre de host a dirección de
red para todo Internet. Antes de que el DNS se generalizara, los archivos que contenían la
misma información se enviaban por correo electrónico o ftp entre todos los hosts en
red. ¡Obviamente, esta metodología no era escalable!

Otros sistemas de información distribuida proporcionan espacio de

nombre_de_usuario/contraseña/ID_de_usuario/ID_de_grupo para una facilidad distribuida.
Los sistemas UNIX han empleado una amplia variedad de métodos de información
distribuida. Sun Microsystems (ahora parte de Oracle Corporation) introdujo las páginas
amarillas (desde que se renombró como servicio de información de red o NIS), y la mayoría
de la industria adoptó su uso. Centraliza el almacenamiento de nombres de usuario,
nombres de host, información de la impresora y similares. Desafortunadamente, utiliza
métodos de autenticación no seguros, incluido el envío de contraseñas de usuario sin cifrar
(en texto sin cifrar) e identificación de hosts por dirección IP. NIS+ de Sun fue un reemplazo
mucho más seguro para NIS, pero fue mucho más complicado y no fue ampliamente
adoptado.

En el caso del sistema de archivos de Internet común de Microsoft (CIFS), la información

de red se usa junto con la autenticación de usuario (nombre de usuario y contraseña) para
crear un inicio de sesión de red que el servidor usa para decidir si permite o deniega el
acceso a un sistema de archivos solicitado. Para que esta autenticación sea válida, los
nombres de usuario deben coincidir de una máquina a otra (como con NFS). Microsoft usa
el directorio activo como una estructura de nombres distribuida para proporcionar un
espacio de nombre único para los usuarios. Una vez establecida, todos los clientes y
servidores utilizan la función de nombres distribuidos para autenticar a los usuarios a través
de la versión de Microsoft del protocolo de autenticación de red Kerberos
(https://web.mit.edu/kerberos/).

La industria se está moviendo hacia el uso del protocolo ligero de acceso a directorios
(LDAP) como un mecanismo de asignación de nombres distribuido seguro. De hecho, el
directorio activo se basa en LDAP. Oracle Solaris y la mayoría de los otros sistemas
operativos importantes incluyen LDAP y permiten su uso para la autenticación de usuarios,
así como para la recuperación de información en todo el sistema, como la disponibilidad de
impresoras. Posiblemente, una organización podría utilizar un directorio LDAP distribuido
para almacenar toda la información de usuarios y recursos de todas las computadoras de la
organización. El resultado sería un inicio de sesión único seguro para los usuarios, que
ingresarían su información de autenticación una vez para acceder a todas las computadoras
dentro de la organización. También facilitaría los esfuerzos de administración del sistema al
combinar, en una ubicación, la información que actualmente se encuentra dispersa en
varios archivos de cada sistema o en diferentes servicios de información distribuida.

Modos de falla
Los sistemas de archivos locales pueden fallar por una variedad de razones, incluida la falla
de la unidad que contiene el sistema de archivos, la corrupción de la estructura del
directorio u otra información de administración del disco (denominada colectivamente
metadatos), falla del controlador de disco, falla del cable y falla del adaptador de host. La
falla del usuario o del administrador del sistema también puede causar la pérdida de
archivos o la eliminación de directorios o volúmenes completos. Muchas de estas fallas
harán que un host se bloquee y se muestre una condición de error, y es posible que se
requiera la intervención humana para reparar el daño.

Los sistemas de archivos remotos tienen aún más modos de falla. Debido a la complejidad
de los sistemas de red y las interacciones requeridas entre máquinas remotas, muchos más
problemas pueden interferir con el funcionamiento correcto de los sistemas de archivos
remotos. En el caso de las redes, la red puede interrumpirse entre dos hosts. Tales
interrupciones pueden resultar de fallas de hardware, mala configuración de hardware o
problemas de implementación de redes. Aunque algunas redes tienen capacidad de
recuperación incorporada, incluidas varias rutas entre hosts, muchas no la tienen. Por tanto,
cualquier fallo puede interrumpir el flujo de comandos DFS.

Considere un cliente en medio de un sistema de archivos remoto. Tiene archivos abiertos

desde el host remoto; entre otras actividades, puede realizar búsquedas en directorios para
abrir archivos, leer o escribir datos en archivos y cerrar archivos. Ahora considere una
partición de la red, una falla del servidor o incluso un apagado programado del servidor. De
repente, el sistema de archivos remoto ya no es accesible. Este escenario es bastante
común, por lo que no sería apropiado que el sistema cliente actuara como lo haría si se
perdiera un sistema de archivos local. Por el contrario, el sistema puede finalizar todas las
operaciones en el servidor perdido o retrasar las operaciones hasta que el servidor vuelva a
estar disponible. Esta semántica de fallas se define e implementa como parte del protocolo
del sistema de archivos remoto. La finalización de todas las operaciones puede provocar la
pérdida de datos y la paciencia de los usuarios. Por lo tanto, la mayoría de los protocolos
DFS hacen cumplir o permiten retrasar las operaciones del sistema de archivos en los hosts
remotos, con la esperanza de que el host remoto vuelva a estar disponible.

Para implementar este tipo de recuperación de fallas, se puede mantener algún tipo de
información de estado tanto en el cliente como en el servidor. Si tanto el servidor como el
cliente mantienen el conocimiento de sus actividades actuales y archivos abiertos, entonces
pueden recuperarse sin problemas de una falla. En la situación en la que el servidor falla
pero debe reconocer que ha montado de forma remota sistemas de archivos exportados y
archivos abiertos, NFS Versión 3 adopta un enfoque simple, implementando un DFS sin
estado. En esencia, asume que una solicitud del cliente para leer o escribir un archivo no se
habría producido a menos que el sistema de archivos se hubiera montado de forma remota
y el archivo se hubiera abierto previamente. El protocolo NFS lleva toda la información
necesaria para ubicar el archivo apropiado y realizar la operación solicitada. De manera
similar, no rastrea qué clientes tienen montados los volúmenes exportados, asumiendo
nuevamente que si llega una solicitud, debe ser legítima. Si bien este enfoque sin estado
hace que NFS sea resistente y bastante fácil de implementar, también lo hace inseguro. Por
ejemplo, un servidor NFS podría permitir solicitudes de lectura o escritura falsificadas. Estos
problemas se abordan en la versión 4 de NFS estándar de la industria, en la que NFS se
hace con estado para mejorar su seguridad, rendimiento y funcionalidad.

Semántica de consistencia
La semántica de consistencia representa un criterio importante para evaluar cualquier
sistema de archivos que admita el uso compartido de archivos. Esta semántica especifica
cómo varios usuarios de un sistema deben acceder a un archivo compartido
simultáneamente. En particular, especifican cuándo las modificaciones de los datos por
parte de un usuario serán observadas por otros usuarios. Esta semántica generalmente se
implementa como código con el sistema de archivos.

La semántica de consistencia está directamente relacionada con los algoritmos de

sincronización de procesos, sin embargo, los complejos algoritmos tienden a no
implementarse en el caso de E/S de archivos debido a las grandes latencias y las lentas
tasas de transferencia de los discos y las redes. Por ejemplo, realizar una transacción
atómica en un disco remoto podría implicar varias comunicaciones de red, varias lecturas y
escrituras de disco, o ambas. Los sistemas que intentan un conjunto tan completo de
funcionalidades tienden a funcionar mal. Se puede encontrar una implementación exitosa de
semánticas de uso compartido complejas en el sistema de archivos de Andrew.

Para la siguiente discusión, asumimos que una serie de accesos a archivos (es decir,
lecturas y escrituras) intentados por un usuario en el mismo archivo siempre están
encerrados entre las operaciones open() y close(). La serie de accesos entre las
operaciones open() y close() conforma una sesión de archivo. Para ilustrar el
concepto, esbozamos varios ejemplos destacados de semántica de consistencia.

Semántica UNIX
El sistema de archivos de UNIX utiliza la siguiente semántica de consistencia:

● Las escrituras de un usuario en un archivo abierto son visibles inmediatamente para

otros usuarios que tienen este archivo abierto.
● Un modo de compartir permite a los usuarios compartir el puntero de la ubicación
actual en el archivo. Por tanto, el avance del puntero por parte de un usuario afecta
a todos los usuarios que comparten. Aquí, un archivo tiene una única imagen que
entrelaza todos los accesos, independientemente de su origen.

En la semántica de UNIX, un archivo está asociado con una única imagen física a la que se
accede como recurso exclusivo. La disputa por esta única imagen provoca retrasos en los
procesos del usuario.
Semántica de sesión
El sistema de archivos de Andrew (OpenAFS) utiliza la siguiente semántica de consistencia:

● Las escrituras de un usuario en un archivo abierto no son visibles inmediatamente

para otros usuarios que tienen el mismo archivo abierto.
● Una vez que se cierra un archivo, los cambios realizados en él son visibles solo en
las sesiones que comienzan más tarde. Las instancias ya abiertas del archivo no
reflejan estos cambios.

De acuerdo con esta semántica, un archivo puede estar asociado temporalmente con varias
imágenes (posiblemente diferentes) al mismo tiempo. En consecuencia, varios usuarios
pueden realizar accesos de lectura y escritura simultáneamente en sus imágenes del
archivo, sin demora. Casi no se aplican restricciones a la programación de accesos.

Semántica de archivos compartidos inmutables

Un enfoque único es el de los archivos compartidos inmutables. Una vez que su creador
declara que un archivo es compartido, no se puede modificar. Un archivo inmutable tiene
dos propiedades clave: su nombre no puede reutilizarse y su contenido no puede
modificarse. Por lo tanto, el nombre de un archivo inmutable significa que el contenido del
archivo es fijo. La implementación de esta semántica en un sistema distribuido es simple,
porque el intercambio es disciplinado (solo lectura).

NFS
Los sistemas de archivos de red NFS son comunes. Por lo general, se integran con la
estructura general de directorios y la interfaz del sistema cliente. NFS es un buen ejemplo
de un sistema de archivos de red cliente-servidor bien implementado y ampliamente
utilizado. Aquí, lo usamos como ejemplo para explorar los detalles de implementación de los
sistemas de archivos de red.

NFS es tanto una implementación como una especificación de un sistema de software para
acceder a archivos remotos a través de LAN (o incluso WAN). NFS es parte de ONC+, que
admiten la mayoría de los proveedores de UNIX y algunos sistemas operativos de PC. La
implementación que se describe aquí es parte del sistema operativo Solaris, que es una
versión modificada de UNIX SVR4. Utiliza el protocolo TCP o UDP / IP (según la red de
interconexión). La especificación y la implementación están entrelazadas en nuestra
descripción de NFS. Siempre que se necesitan detalles, nos referimos a la implementación
de Solaris; siempre que la descripción sea general, también se aplica a la especificación.

Hay varias versiones de NFS, siendo la última la versión 4. Aquí describimos la versión 3,
que es la versión más comúnmente implementada.
Descripción
NFS ve un conjunto de estaciones de trabajo interconectadas como un conjunto de
máquinas independientes con sistemas de archivos independientes. El objetivo es permitir
cierto grado de intercambio entre estos sistemas de archivos (bajo pedido explícito) de
manera transparente. El intercambio se basa en una relación cliente-servidor. Una máquina
puede ser, y a menudo lo es, tanto un cliente como un servidor. Se permite compartir entre
cualquier par de máquinas. Para garantizar la independencia de la máquina, compartir un
sistema de archivos remoto afecta solo a la máquina cliente y a ninguna otra máquina.

Para que un directorio remoto sea accesible de manera transparente desde una máquina en
particular, por ejemplo, desde M1, un cliente de esa máquina debe realizar primero una
operación de montaje. La semántica de la operación implica montar un directorio remoto
sobre un directorio de un sistema de archivos local. Una vez que se completa la operación
de montaje, el directorio montado se ve como un subárbol integral del sistema de archivos
local, reemplazando el subárbol que desciende del directorio local. El directorio local se
convierte en el nombre de la raíz del directorio recién montado. La especificación del
directorio remoto como argumento para la operación de montaje no se realiza de forma
transparente; se debe proporcionar la ubicación (o nombre de host) del directorio remoto.
Sin embargo, a partir de ese momento, los usuarios de la máquina M1 pueden acceder a los
archivos del directorio remoto de forma totalmente transparente.

Para ilustrar el montaje de archivos, considere el sistema de archivos que se muestra en la

figura 6, donde los triángulos representan subárboles de directorios que son de interés. La
figura muestra tres sistemas de archivos independientes de máquinas denominadas U, S1 y
S2. En este punto, en cada máquina, solo se puede acceder a los archivos locales. La figura
7 (a) muestra los efectos de montar S1:/usr/shared sobre U:/usr/local. Esta figura
muestra la vista que los usuarios de U tienen de su sistema de archivos. Una vez
completado el montaje, pueden acceder a cualquier archivo dentro del directorio dir1
usando el prefijo /usr/local/dir1. El directorio original /usr/local en esa máquina
ya no es visible.

Sujeto a la acreditación de derechos de acceso, cualquier sistema de archivos o cualquier

directorio dentro del sistema de archivos, se puede montar de forma remota en la parte
superior de cualquier directorio local.
Las estaciones de trabajo sin disco pueden incluso montar sus propias raíces desde
servidores. Los montajes en cascada también están permitidos en algunas
implementaciones de NFS. Es decir, un sistema de archivos se puede montar sobre otro
sistema de archivos que está montado de forma remota, no local. Una máquina se ve
afectada solo por los montajes que ella misma ha invocado. Montar un sistema de archivos
remoto no le da al cliente acceso a otros sistemas de archivos que, por casualidad, estaban
montados sobre el sistema de archivos anterior. Por tanto, el mecanismo de montaje no
presenta propiedad de transitividad.

En la figura 7 (b), ilustramos montajes en cascada. La figura muestra el resultado de montar

S2:/usr/dir2 sobre U:/usr/local/dir1, que ya está montado remotamente desde
S1. Los usuarios pueden acceder a archivos dentro de dir2 en U usando el prefijo
/usr/local/dir1. Si un sistema de archivos compartido está montado en los directorios
de inicio de un usuario en todas las máquinas de una red, el usuario puede iniciar sesión en
cualquier estación de trabajo y obtener su entorno personal. Esta propiedad permite la
movilidad del usuario.

Uno de los objetivos de diseño de NFS era operar en un entorno heterogéneo de diferentes
máquinas, sistemas operativos y arquitecturas de red. La especificación NFS es

independiente de estos medios. Esta independencia se logra mediante el uso de primitivas

RPC construidas sobre un protocolo de representación de datos externos (XDR) utilizado
entre dos interfaces independientes de la implementación. Por lo tanto, si las máquinas
heterogéneas y los sistemas de archivos del sistema están conectados correctamente a
NFS, los sistemas de archivos de diferentes tipos se pueden montar tanto de forma local
como remota.

La especificación NFS distingue entre los servicios proporcionados por un mecanismo de

montaje y los servicios reales de acceso a archivos remotos. En consecuencia, se
especifican dos protocolos separados para estos servicios: un protocolo de montaje y un
protocolo para accesos remotos a archivos, el protocolo NFS. Los protocolos se
especifican como conjuntos de RPC. Estos RPC son los componentes básicos que se
utilizan para implementar el acceso transparente a archivos remotos.
El protocolo de montaje
El protocolo de montaje establece la conexión lógica inicial entre un servidor y un cliente.
En Solaris, cada máquina tiene un proceso servidor, fuera del kernel, que realiza las
funciones del protocolo.

Una operación de montaje incluye el nombre del directorio remoto que se va a montar y el
nombre de la máquina servidor que lo almacena. La solicitud de montaje se asigna al RPC
correspondiente y se reenvía al servidor de montaje que se ejecuta en la máquina del
servidor específico. El servidor mantiene una lista de exportación que especifica los
sistemas de archivos locales que exporta para el montaje, junto con los nombres de las
máquinas que pueden montarlos. (En Solaris, esta lista es /etc/dfs/dfstab, que solo
puede editar un superusuario). La especificación también puede incluir derechos de acceso,
como solo lectura. Para simplificar el mantenimiento de listas de exportación y tablas de
montaje, se puede utilizar un esquema de nombres distribuido para mantener esta
información y ponerla a disposición de los clientes apropiados.

Recuerde que cualquier directorio dentro de un sistema de archivos exportado puede

montarse de forma remota mediante una máquina acreditada. Una unidad de componente
es un directorio de este tipo. Cuando el servidor recibe una solicitud de montaje que se
ajusta a su lista de exportación, devuelve al cliente un identificador de archivo que sirve
como clave para más accesos a los archivos dentro del sistema de archivos montado. El
identificador de archivo contiene toda la información que el servidor necesita para distinguir
un archivo individual que almacena. En términos de UNIX, el identificador de archivo consta
de un identificador de sistema de archivos y un número de inodo para identificar el directorio
exacto montado dentro del sistema de archivos exportado.

El servidor también mantiene una lista de las máquinas cliente y los correspondientes
directorios montados actualmente. Esta lista se utiliza principalmente con fines
administrativos, por ejemplo, para notificar a todos los clientes que el servidor no funciona.
Solo mediante la adición y eliminación de entradas en esta lista, el protocolo de montaje
puede afectar el estado del servidor.

Por lo general, un sistema tiene una configuración previa de montaje estático que se
establece en el momento del arranque (/etc/vfstab en Solaris); sin embargo, este
diseño se puede modificar. Además del procedimiento de montaje real, el protocolo de
montaje incluye varios otros procedimientos, como desmontar y devolver la lista de
exportación.

El protocolo NFS
El protocolo NFS proporciona un conjunto de RPCs para operaciones de archivos remotos.
Los procedimientos admiten las siguientes operaciones:

● Búsqueda de un archivo dentro de un directorio

● Lectura de un conjunto de entradas de directorio
● Manipulación de enlaces y directorios
● Acceso a atributos de archivo
 ● Lectura y escritura de archivos

Estos procedimientos se pueden invocar solo después de que se haya establecido un

identificador de archivo para el directorio montado de forma remota.

La omisión de operaciones de apertura y cierre es intencional. Una característica destacada

de los servidores NFS es que no tienen estado. Los servidores no mantienen información
sobre sus clientes de un acceso a otro. No existen paralelos con la tabla de archivos
abiertos de UNIX o las estructuras de archivos en el lado del servidor. En consecuencia,
cada solicitud debe proporcionar un conjunto completo de argumentos, incluido un
identificador de archivo único y un desplazamiento absoluto dentro del archivo para las
operaciones adecuadas. El diseño resultante es robusto; no es necesario tomar medidas
especiales para recuperar un servidor después de un bloqueo. Las operaciones de archivo
deben ser idempotentes para este propósito, es decir, la misma operación realizada varias
veces debe tener el mismo efecto que si solo se hubiera realizado una vez. Para lograr la
idempotencia, cada solicitud de NFS tiene un número de secuencia, lo que permite al
servidor determinar si una solicitud se ha duplicado o si falta alguna.

Mantener la lista de clientes que mencionamos parece violar la apatridia del servidor. Sin
embargo, esta lista no es esencial para el correcto funcionamiento del cliente o del servidor
y, por lo tanto, no es necesario restaurarla después de una caída del servidor. En
consecuencia, puede incluir datos inconsistentes y se trata solo como una sugerencia.

Una implicación adicional de la filosofía del servidor sin estado y un resultado de la

sincronía de un RPC es que los datos modificados (incluidos los bloques de estado y
direccionamiento indirecto) deben enviarse al disco del servidor antes de que los resultados
se devuelvan al cliente. Es decir, un cliente puede almacenar en caché bloques de escritura,
pero cuando los descarga al servidor, asume que han llegado a los discos del servidor. El
servidor debe escribir todos los datos NFS de forma sincrónica. Por lo tanto, una falla del
servidor y la recuperación serán invisibles para un cliente; todos los bloques que el servidor
está administrando para el cliente estarán intactos. La penalización de rendimiento
resultante puede ser grande, porque se pierden las ventajas del almacenamiento en caché.
El rendimiento se puede aumentar mediante el uso de almacenamiento con su propia caché
no volátil (generalmente memoria con respaldo de batería). El controlador de disco
reconoce la escritura en disco cuando la escritura se almacena en la caché no volátil. En
esencia, el host ve una escritura sincrónica muy rápida. Estos bloques permanecen intactos
incluso después de una falla del sistema y se escriben desde este almacenamiento estable
en el disco periódicamente.

Se garantiza que una sola llamada al procedimiento de escritura NFS sea atómica y no se
entremezcle con otras llamadas de escritura al mismo archivo. Sin embargo, el protocolo
NFS no proporciona mecanismos de control de simultaneidad. La llamada al sistema
write() se puede dividir en varias escrituras RPC, porque cada llamada write() o
read() NFS puede contener hasta 8 KB de datos y los paquetes UDP están limitados a
1500 bytes. Como resultado, dos usuarios que escriben en el mismo archivo remoto pueden
mezclar sus datos. La afirmación es que, debido a que la administración de bloqueos es
intrínsecamente con estado, un servicio fuera del NFS debería proporcionar bloqueo (y
Solaris lo hace). Se aconseja a los usuarios que coordinen el acceso a los archivos
compartidos mediante mecanismos fuera del alcance de NFS.
NFS está integrado en el sistema operativo a través de un VFS. Como ilustración de la
arquitectura, rastreamos cómo se maneja una operación en un archivo remoto ya abierto
(siga el ejemplo de la figura 8). El cliente inicia la operación con una llamada regular al
sistema. La capa del sistema operativo asigna esta llamada a una operación VFS en el
vnode apropiado. La capa VFS identifica el archivo como remoto e invoca el procedimiento
NFS apropiado. Se realiza una llamada RPC a la capa de servicio NFS en el servidor
remoto. Esta llamada se reinyecta a la capa VFS en el sistema remoto, que encuentra que
es local e invoca la operación apropiada del sistema de archivos. Esta ruta se recorre para
devolver el resultado. Una ventaja de esta arquitectura es que el cliente y el servidor son
idénticos; por tanto, una máquina puede ser un cliente, un servidor o ambos. El servicio real
en cada servidor se realiza mediante hilos del núcleo.

Traducción de nombre de ruta

La traducción de nombre de ruta en NFS implica el análisis de un nombre de ruta como
/usr/local/dir1/file.txt en entradas de directorio separadas, o componentes: (1)
usr, (2) local, y (3) dir1. La traducción del nombre de la ruta se realiza dividiendo la ruta
en nombres de componentes y realizando una llamada de búsqueda NFS separada para
cada par de nombre de componente y directorio vnode. Una vez que se cruza un punto de
montaje, cada búsqueda de componentes genera una RPC separada para el servidor. Este
costoso esquema de ruta-nombre-recorrido es necesario, ya que el diseño del espacio de
nombres lógicos de cada cliente es único, dictado por los montajes que el cliente ha
realizado. Sería mucho más eficiente entregarle a un servidor un nombre de ruta y recibir un
vnode de destino una vez que se encuentre un punto de montaje. En cualquier momento,
sin embargo, puede haber otro punto de montaje para el cliente en particular del que el
servidor sin estado desconozca.
Para que la búsqueda sea rápida, un caché de búsqueda de nombres de directorio en el
lado del cliente contiene los vnodes para los nombres de directorios remotos. Esta caché
acelera las referencias a archivos con el mismo nombre de ruta inicial. La caché del
directorio se descarta cuando los atributos devueltos por el servidor no coinciden con los
atributos del vnode en caché.

Recuerde que algunas implementaciones de NFS permiten montar un sistema de archivos

remoto sobre otro sistema de archivos remoto ya montado (un montaje en cascada).
Cuando un cliente tiene un montaje en cascada, más de un servidor puede estar
involucrado en un cruce de nombre de ruta. Sin embargo, cuando un cliente realiza una
búsqueda en un directorio en el que el servidor ha montado un sistema de archivos, el
cliente ve el directorio subyacente en lugar del directorio montado.

Operaciones remotas
Con la excepción de abrir y cerrar archivos, existe una correspondencia casi uno a uno
entre las llamadas regulares al sistema UNIX para operaciones de archivos y las RPC del
protocolo NFS. Por lo tanto, una operación de archivo remoto se puede traducir
directamente al RPC correspondiente. Conceptualmente, NFS se adhiere al paradigma de
servicio remoto; pero en la práctica, las técnicas de almacenamiento en búfer y caché se
emplean en aras del rendimiento. No existe correspondencia directa entre una operación
remota y un RPC. En su lugar, los bloques de archivo y los atributos de archivo son
recuperados por los RPC y se almacenan en caché localmente. Las operaciones remotas
futuras utilizan los datos almacenados en caché, sujetos a restricciones de consistencia.

Hay dos cachés: el caché de atributos de archivo (información de inodo) y el caché de

bloques de archivos. Cuando se abre un archivo, el kernel verifica con el servidor remoto
para determinar si debe recuperar o revalidar los atributos almacenados en caché. Los
bloques de archivos en caché se utilizan solo si los atributos en caché correspondientes
están actualizados. La caché de atributos se actualiza cada vez que llegan nuevos atributos
del servidor. Los atributos almacenados en caché se descartan, de forma predeterminada,
después de 60 segundos. Se utilizan técnicas de lectura anticipada y de escritura retardada
entre el servidor y el cliente. Los clientes no liberan bloques de escritura retardada hasta
que el servidor confirma que los datos se han escrito en el disco. La escritura retrasada se
retiene incluso cuando se abre un archivo al mismo tiempo, en modos conflictivos. Por
tanto, la semántica de UNIX no se conserva.

El ajuste del sistema para el rendimiento dificulta la caracterización de la semántica de

consistencia de NFS. Es posible que los archivos nuevos creados en una máquina no sean
visibles en otros lugares durante 30 segundos. Además, las escrituras en un archivo en un
sitio pueden o no ser visibles en otros sitios que tienen este archivo abierto para lectura. Las
nuevas aperturas de un archivo observan solo los cambios que ya se han descargado en el
servidor. Por lo tanto, NFS no proporciona ni una emulación estricta de la semántica de
UNIX ni la semántica de sesión de Andrew. A pesar de estos inconvenientes, la utilidad y el
buen rendimiento del mecanismo lo convierten en el sistema distribuido de múltiples
proveedores más ampliamente utilizado en funcionamiento.