Sistemas de Archivos Distribuidos

Sistemas de Archivos Distribuidos

Por:Castorani, CarlosCorrea, FabianDe Sousa, ChristianPereira, José ManuelWalzer, Carlos

CI-4821. Sistemas de Operación IIUniversidad Simón Bolívar, 28 septiembre 2005


1. Introducción1.1 Características de los Sistemas de Archivo.1.2 Requerimientos de los Sistemas de Archivos Distribuidos.

2. Arquitectura del Sistema de Archivos3. Sun Network File System 3.1 El Paradigma y su optimalidad.4. The Andrew File System 4.1 El Paradigma y su optimalidad.5. Comparación6. Conclusiones: Mejoras.

Índice


1. Introducción

CI-4821, sep-dic 2005

Los sistemas de archivo distribuidos permiten almacenar y acceder archivos remotos de la misma manera como si fueran locales, permitiendo que el usuario haga uso de los archivos de cualquier computador en una red.El desempeño y confiabilidad son las principales características y se deben poder comparar con el rendimiento y manejo local.

En este trabajo describiremos una arquitectura simple de unSistema de archivos y presentaremos las implementaciones de

Sun Network File System, NFS y The Andrew Network File System.

Cada uno de estos emula la interfaz del sistema de archivos de UNIX con distintos niveles de escalabilidad, tolerancia a fallos y semántica de actualizaciones.


CI-4821, sep-dic 2005

Figura 1. Tipos de sistemas de almacenamiento

Sharing Persis-tence

Distributedcache/replicas

Consistencymaintenance

Example

Main memory RAM

File system UNIX file system

Distributed file system Sun NFS

Web Web server

Distributed shared memory Ivy

Remote objects (RMI/ORB) CORBA

Persistent object store 1 CORBA PersistentObject Service

Peer-to-peer storage system OceanStore

1

1

1

2

Tipos de Consistencia: 1: Sólo una copia. : Garantías ligeramente débiles. 2: Garantías considerablemente débiles.


1. Introducción 1.1. Características

de los Sistemas de Archivo.

CI-4821, sep-dic 2005

Directory module: relates file names to file IDs

File module: relates file IDs to particular files

Access control module: checks permission for operation requested

File access module: reads or writes file data or attributes

Block module: accesses and allocates disk blocks

Device module: disk I/O and buffering

Figura 2. Estructura de Módulos


CI-4821, sep-dic 2005

Figura 3. Operaciones del sistema de Archivos de UNIX

filedes = open(name, mode)filedes = creat(name, mode)

Opens an existing file with the given name. Creates a new file with the given name. Both operations deliver a file descriptor referencing the openfile. The mode is read, write or both.

status = close(filedes) Closes the open file filedes.count = read(filedes, buffer, n)count = write(filedes, buffer, n)

Transfers n bytes from the file referenced by filedes to buffer. Transfers n bytes to the file referenced by filedes from buffer.Both operations deliver the number of bytes actually transferredand advance the read-write pointer.

pos = lseek(filedes, offset, whence)

Moves the read-write pointer to offset (relative or absolute,depending on whence).

status = unlink(name) Removes the file name from the directory structure. If the filehas no other names, it is deleted.

status = link(name1, name2) Adds a new name (name2) for a file (name1). status = stat(name, buffer) Gets the file attributes for file name into buffer.




1.2. Requerimientode los Sistemasde Archivos Distribuidos.

CI-4821, sep-dic 2005

a. Transparencia.Se debe balancear la flexibilidad y la escalabilidad que derivan de la transparencia, contra la complejidad del software y el desempeño.

Acceso: Los programas del cliente deben desconocer la distribución de los archivos. Un simple conjunto de operaciones debe proveer el acceso local y remoto. Programas escritos para operar en archivos locales deben se capaces de acceder archivos remotos sin modificaciones.

Localidad: Los programas del cliente deben ver un espacio de nombres de archivos uniforme. Los archivos podrán ser reubicados sin cambiar la ruta de sus nombres.

Movilidad: Ni los programas de los clientes ni las tablas de administración del sistema necesitarán ser cambiadas cuando los archivos son movidos. Esto permite la movilidad de archivos – volumenes completos pueden ser movidos, por el administrador del sistema o automaticamente





CI-4821, sep-dic 2005

…a.Transparencia.

Desempeño: Los programas del cliente deben continuar desempeñándose satisfactoriamente mientras la carga del servidor varíe en un rango específico.

Escalabilidad: El servicio puede expandirse con un crecimiento que maneje un alto rango de cargas y tamaños de las redes.

b. Actualización Concurrente de Archivos.Cambios a un archivo por parte de un cliente, no debe interferir con las operaciones de otros clientes que simultáneamente acceden el mismo archivo.(control de concurrencia)

c. Archivos replicados.Un archivo debe ser representado por varias copias de su contenido en distintas localidades.





CI-4821, sep-dic 2005

d. Sistemas HeterogéneosEl servicio debe ser definido de manera que el cliente y el servidor puedan ser implementados por diferentes sistemas de operación y computadores.

e. Tolerancia a FallasEs esencial que el sistema continúe funcionando en el caso de que el cliente o el servidor fallen.

f. ConsistenciaUnix one-copy update semantics. Cuando los archivos son replicados o colocados en cache en distintas localidades, existe un retraso inevitable en la propagación de las modificaciones que puede derivar en problemas de consistencia.





CI-4821, sep-dic 2005

g. Seguridad.En sistemas distribuidos existe la necesidad de autenticar la petición del cliente. Además protege el contenido de los mensajes de petición y respuesta con firmas digitales y encriptamiento.

h. Eficiencia.Apegados lo más posible a los sistemas de archivos convencionales: con desempeño comparable.


2. Arquitectura del Sistema de Archivos

CI-4821, sep-dic 2005

Client computer Server computer

Applicationprogram

Applicationprogram

Client module

Flat file service

Directory service

Figura 4. Arquitectura del sistema de archivos



CI-4821, sep-dic 2005

a. Flat File Service. Se encarga de implementar operaciones sobre el contenido de los archivos.

b. Directory ServiceProvee el mapeo entre nombres de texto para archivos y sus UFIDs (Unique file Identifier). Provee funciones necesarias para generar directorios.

c. Client ModuleCorre en cada cliente, integrando y extendiendo las operaciones de el flat file service y el directory service bajo una aplicación simple que esta disponible a nivel de usuario en el cliente.

d. Flat File Service InterfaceEsta es la interfaz de RPC usada por los módulos del cliente. Normalmente usada directamente por programas a nivel de usuario. La Figura 5, contiene la definición de la interfaz para el flat file service.



CI-4821, sep-dic 2005

Figura 5. Arquitectura del sistema de archivos

Read(FileId, i, n) -> Data — throws BadPosition

If 1 ≤ i ≤ Length(File): Reads a sequence of up to n itemsfrom a file starting at item i and returns it in Data.

Write(FileId, i, Data) — throws BadPosition

If 1 ≤ i ≤ Length(File)+1: Writes a sequence of Data to afile, starting at item i, extending the file if necessary.

Create() -> FileId Creates a new file of length 0 and delivers a UFID for it. Delete(FileId) Removes the file from the file store.GetAttributes(FileId) -> Attr Returns the file attributes for the file. SetAttributes(FileId, Attr) Sets the file attributes (only those attributes that are not

shaded in Figure 8.3).



CI-4821, sep-dic 2005

e. Access controlLos permisos de acceso del cliente, en UFS, son chequeados con el modo de acceso pedido (read o write) en la llamada abierta. En implementaciones distribuidas, el chequeo de los permisos de acceso deben ser realizados en el servidor, ya que sino la interfaz del servidor RPC sería un punto de acceso desprotegido.

f. Directory Service InterfaceSu principal función es proveer un servicio para traducir los nombres de texto a UFID. Para esto, mantiene archivos de directorios que contienen el mapeo entre nombre de texto y UFID.

La Figura 6, contiene una definición de la interfaz del RPC al servicio de directorio.



CI-4821, sep-dic 2005

Lookup(Dir, Name) -> FileId— throws NotFound

Locates the text name in the directory and returns therelevant UFID. If Name is not in the directory, throws anexception.

AddName(Dir, Name, FileId) — throws NameDuplicate

If Name is not in the directory, adds (Name, File) to thedirectory and updates the file’s attribute record.If Name is already in the directory: throws an exception.

UnName(Dir, Name) — throws NotFound

If Name is in the directory: the entry containing Name isremoved from the directory. If Name is not in the directory: throws an exception.

GetNames(Dir, Pattern) -> NameSeq Returns all the text names in the directory that match theregular expression Pattern.

Figura 6. Operaciones del servicio de Directorio



CI-4821, sep-dic 2005

g. Hierarchic File SystemUNIX provee un número de directorios con una estructura tipo árbol.Una red con estructura de directorios tipo árbol, está construida con archivos en las hojas y directorios en los otros nodos del árbol. La raíz es un directorio con un UFID “bien conocido”.

h. File GroupsEs una colección de archivos localizados en un servidor dado. Pueden ser movidos entre servidores, pero un archivo no puede cambiarse del grupo al que pertenece.

32bits 16bitsidentificador del Grupo de archivos IP address date


3. Sun File System

CI-4821, sep-dic 2005

Todas las implementaciones de NFS soportan el protocolo NFS – un conjunto de llamadas a procedimientos que proceen el medio para que los clientes desempeñen operaciones sobre un sistema de almacenamiento de archivo remoto - .Es sistema-operativo-independiente, pero fue inicialmente desarrollado para ser usado en sistemas de redes UNIX.

El módulo del servidor NFS reside en el kernel de cada computador que actúa como un servidor NFS. Peticiones que se refieren a archivos en un sistemas de archivos remotos, son traducidos por el módulo del cliente a operaciones de protocolo NFS y luego pasadas al módulo del servidor NFS en el computador que posee el sistema de archivos correspondiente.

La Figura 7 muestra la arquitectura de Sun NFS.


CI-4821, sep-dic 2005

UNIX kernel

protocol

Client computer Server computer

system calls

Local Remote

UNIXfile

system

NFSclient

NFSserver

UNIXfile

system

Applicationprogram

Applicationprogram

NFS

UNIX

UNIX kernel

Virtual file systemVirtual file system

Oth

er fi

le s

yste

m

Figura 7. Operaciones del servicio de Directorio


3. Sun File System

CI-4821, sep-dic 2005

Sistema de Archivo Virtual

La integración se da gracias al módulo del sistema de archivo virtual (virtual file system – VFS), que ha sido agregado al kernel de UNIX para distinguir entre archivos locales y remotos y para traducir entre el identificador de archivos independiente de UNIX usado por NFS y el identificador de archivos interno normalmente usado por UNIX y otros sistemas de archivos.

El identificador de archivos usado en NFS es llamado file handles. No es visible al cliente y contiene la información que el servidor requiere para distinguir un archivo individual.

Utiliza vnodes ( virtual node ) para indicar si un archivo abierto es local o remoto. Hace referencia a un inode ( UNIX ) o un rnode ( remote node )


3. Sun File System

CI-4821, sep-dic 2005

Integración del Cliente

El módulo del cliente NFS juega el rol descrito para el módulo en nuestro modelo de arquitectura.

Permite una interfaz para se usado por aplicaciones convencionales

Sin embargo, nuestro modelo emula la semántica de las primitivas del sistema de archivos estándar de UNIX y está integrado a su kernel. Tiene ventajas usarlo en el Kernel y no como una libreria


3. Sun File System

CI-4821, sep-dic 2005

Autenticación y control de acceso

A diferencia de los sistemas de archivo convencionales de UNIX, el servidor NFS es Sin Estados y no deja archivos abiertos del lado del servidor.

El protocolo RPC de SUN exige que los clientes envíen la información de autenticación con cada petición y esto es chequeado con los permisos de acceso en los atributos de los archivos.

Ya que un servidor NFS provee una interfaz RPC convencional en un puerto “bien conocido”, esto puede crear un hueco en la seguridad ya que cualquier proceso se puede comportar como cliente.

La integración de NFS con Kerberos, provee una solución más fuerte y comprensiva sobre los problemas de autenticación de usuario y seguridad.


CI-4821, sep-dic 2005

Figura 8. Operaciones del servidor NFS – 1

lookup(dirfh, name) -> fh, attr Returns file handle and attributes for the file name in the directory dirfh.

create(dirfh, name, attr) -> newfh, attr

Creates a new file name in directory dirfh with attributes attr andreturns the new file handle and attributes.

remove(dirfh, name) status Removes file name from directory dirfh.getattr(fh) -> attr Returns file attributes of file fh. (Similar to the UNIX stat system

call.)setattr(fh, attr) -> attr Sets the attributes (mode, user id, group id, size, access time and

modify time of a file). Setting the size to 0 truncates the file.read(fh, offset, count) -> attr, data Returns up to count bytes of data from a file starting at offset.

Also returns the latest attributes of the file.write(fh, offset, count, data) -> attr Writes count bytes of data to a file starting at offset. Returns the

attributes of the file after the write has taken place.rename(dirfh, name, todirfh, toname)

-> statusChanges the name of file name in directory dirfh to toname indirectory to todirfh.

link(newdirfh, newname, dirfh, name) -> status

Creates an entry newname in the directory newdirfh which refers tofile name in the directory dirfh.

Continúa en la próxima lámina…


CI-4821, sep-dic 2005

Figura 8. Operaciones del servidor NFS – 2

symlink(newdirfh, newname, string)-> status

Creates an entry newname in the directory newdirfh of typesymbolic link with the value string. The server does not interpretthe string but makes a symbolic link file to hold it.

readlink(fh) -> string Returns the string that is associated with the symbolic link fileidentified by fh.

mkdir(dirfh, name, attr) -> newfh, attr

Creates a new directory name with attributes attr and returns thenew file handle and attributes.

rmdir(dirfh, name) -> status Removes the empty directory name from the parent directory dirfh.Fails if the directory is not empty.

readdir(dirfh, cookie, count) -> entries

Returns up to count bytes of directory entries from the directorydirfh. Each entry contains a file name, a file handle, and an opaquepointer to the next directory entry, called a cookie. The cookie isused in subsequent readdir calls to start reading from the followingentry. If the value of cookie is 0, reads from the first entry in thedirectory.

statfs(fh) -> fsstats Returns file system information (such as block size, number offree blocks and so on) for the file system containing a file fh.


3. Sun File System

CI-4821, sep-dic 2005

Interfaz del servidor NFS

Las operaciones de acceso a archivos read, write, getattr y setattr; son casi idénticas a las operaciones definidas por nuestro modelo de servicios Flat File. Ver figuras 5,6,8.

Las operaciones sobre archivos y directorios están integradas en un solo servicio. La creación e inserción de archivos en directorios es realizada por la misma operación create.

El resto de las operaciones sobre directorios son similares a su contraparte en UNIX: remove, rename link, symlink, readink, mkdir, rmdir, readdir y statfs; a diferencia de readdir, que provee una representación independiente al leer directorios y statfs: que da el status sobre el sistema de archivos remoto.


3. Sun File System

CI-4821, sep-dic 2005

Servicio Mount

Es un servicio separado que corre a nivel de usuario en cada servidor NFS. En cada servidor, hay un archivo con un nombre “bien conocido” (etc/export) que contiene los nombre de los sistemas de archivos locales que están disponibles para ser “montados” remotamente.

Los Clientes utilizan una versión modificada del comando mount al cual se le especifica el servidor y el directorio remoto que se desea montar localmente.

La dirección (IP y puerto) del servidor y el archivo manejado para el directorio remoto, son pasados por la capa VFS y el cliente NFS.Ver figura 9

Puede ser realizado de manera Hard-mounted o Soft-mounted


3. Sun File System

CI-4821, sep-dic 2005

jim jane joeann

usersstudents

usrvmunix

Client Server 2

. . . nfs

Remote

mountstaff

big bobjon

people

Server 1

export

(root)

Remote

mount

. . .

x

(root) (root)

Note: The file system mounted at /usr/students in the client is actually the sub-tree located at /export/people in Server 1; the file system mounted at /usr/staff in the client is actually the sub-tree located at /nfs/users in Server 2.

Figura 9. Acceso local y remoto al sistema de archivos en un cliente NFS


3. Sun File System

CI-4821, sep-dic 2005

Traducción del nombre de ruta

En NFS, a diferencia de UNIX, la ruta de nombres (pathnames) no pueden ser traducidas al servidor ya que el nombre podría cruzar un mount point del lado del cliente. El pathnames es entonces “parseado” y su traducción es hecha de manera iterativa por el cliente:Lookup operation.

La operación Lookup busca solo por una parte del pathname en un directorio y retorna su correspondiente file handle y file atributes


3. Sun File System

CI-4821, sep-dic 2005

Automounter

Fue agregado a la implementación de UNIX de NFS para “montar” un directorio remoto dinámicamente en el momento en que un “mount point” vacío sea referenciado por el cliente.

Mantiene una tabla de “mount points” (pathnames) con una referencia a uno o más servidores NFS listado. Se comporta como un servidor NFS local del lado del cliente.


3. Sun File System

CI-4821, sep-dic 2005

Caching del Servidor

Usado para el desempeño adecuado del cliente y del servidor NFS.UNIX mantiene en memoria cache: páginas, directorios y atributos de archivos que son leídos de disco. Esto funciona porque todas las operaciones de read-write pasan por un solo cache implementado en el kernel de UNIX.

NFS usa el cache del lado del servidor. Esto no implica problemas de consistencia; sin embargo, cuando se llevan a cabo operaciones de escritura, es necesario medidas especiales.


3. Sun File System

CI-4821, sep-dic 2005

Caching del Cliente

Crea posibles diferencias en la información de los archivos (o porción de archivos) que existen en distintos clientes (nodos de clientes) ya que las escrituras en clientes no resultan en actualizaciones inmediatas en los demás.

Los clientes son responsables por consultar (polling) al servidor por la actualización de la información en cache que ellos poseen.

Timestamp-based method : (para validación de cache )

Tc es el tiempo de la última validación de la entrada a cache.Tm es el tiempo de la última modificación del bloque en el servidor.t intervalo de refrescamiento.

(T – Tc < t) v (Tmcliente = Tmservidor)


3. Sun File System

CI-4821, sep-dic 2005

Otras optimizaciones

NFS está basado en UNIX BSD Fast File System que utiliza bloques de disco de 8kb y que genera menos llamadas al sistema de archivo para acceso secuencial de archivos, que el sistema UNIX anterior.

Los paquetes UDP usados para la implementación de Sun RPC se extiende a bloques de 9kb. En la versión 3 de NFS, se negocian tamaños de bloque mayores a 8 kb, entre clientes y servidores.


3. Sun File System

CI-4821, sep-dic 2005

Desempeño

Áreas problemáticas, según Sandberg:

1.El uso frecuente de las llamadas a getattr para obtener timestamp para el servidor en las validaciones de cache.

2.Pobre desempeño de las operaciones de escritura por que está se realiza a través del servidor (bottleneck).


3. Sun File System

CI-4821, sep-dic 2005

Conclusión Su diseño provee buen direccionamiento y transparencia en el acceso.

Soporta heterogeneidad.

Es sin estados, haciendo que cliente y servidor reactiven la ejecución luego de una falla sin un procedimiento de recuperación.

No soporta migración de archivos o sistemas de archivos (sólo manual).

Se aleja un poco de la semántica de sólo una copia de UNIX con el desempeño de los bloques de cache en el cliente.


3. Sun File System

CI-4821, sep-dic 2005

Transparencia en el acceso: El módulo del cliente NFS provee una interfaz de programación de aplicaciones, idéntica al sistema de operación local ( UNIX ). Por lo tanto es total.

Transparencia de localidad: No es forzado mas con una buena configuración es posible hacerlo.

Transparencia de movilidad: No es lograda totalmente ya que los clientes tienen que actualizar individualmente sus puntos de montaje

Escalabilidad: Puede manejar cargas muy grandes, con bastante eficiencia.


3. Sun File System

CI-4821, sep-dic 2005

Replicación de Archivos: Solo los archivos de lectura pueden ser replicados

Heterogeneidad de SO: Ha sido implementado en casi todos los SO

Tolerancia a Fallas: Al ser sin estados, son observados como errores del sistema local

Consistencia : Se aproxima a la semántica de una sola copia de UNIX.

Seguridad : Con uso de Kerberos.

Eficiencia : Ya ha sido probado en el mundo real lo eficiente que puede llegar a ser bajo cargas pesadas


4. The Andrew File System

CI-4821, sep-dic 2005

Al igual que NFS, AFS provee acceso a archivos compartidos de manera remota. El acceso a AFS es por la vía normal de las primitivas de archivos de UNIX (sin modificaciones ni recompilaciones).

Se diferencia de NFS, principalmente por su diseño e implementación. La escalabilidad es el elemento meta de diseño más importante: caching completo de todos los archivos en los nodos del cliente. Se desempeña muy bien con altos números de usuarios activos.

Características:Whole-file serving: el contenido completo de los

archivos y directorios son transmitidos al cliente: en cache.

Whole-file caching: una vez que se pasa información al cliente es colocada en cache en el disco local: permanentemente – peticiones abiertas sobre copias remotas.



CI-4821, sep-dic 2005

Escenario

•Cuando un proceso de usuario en el cliente hace una llamada a sistema – abierta – (de un archivo en el espacio compartido) y no es una copia en el cache local, se ubica el servidor que posee el archivo y se le solicita.

•La copia es almacenada en el UFS local del cliente. La copia es abierta y el file descriptor resultante de UNIX vuelve al cliente.

•Operaciones read-write y otras sobre el archivo, por proceso, son aplicadas a la copia local.

•Cuando el proceso en el cliente hace una llamada a sistema, si la copia local ha sido actualizada su contenido es enviado al servidor. El servidor actualiza el contenido del archivo y el timestamps. La copia en el disco local del cliente se conserva en caso de ser necesitada por procesos a nivel de usuario en el mismo grupo.



CI-4821, sep-dic 2005

Observaciones

• Las copias locales en cache probablemente son válidas por largo períodos.

• Este cache local puede ser ubicado en una proporción substanciosa del espacio en disco.

• La estrategia de diseño se basa en ciertas asunciones:•Los archivos son pequeños•Operaciones de read over write•Acceso secuencial •Usuario común•Los archivos son referenciados drásticamente. LRU

• No contempla las complicaciones de las bases de datos.



CI-4821, sep-dic 2005

Implementación

¿Cómo AFS controla cuando una llamada – abierta o cerrada – al sistema, referente a un archivo en el área compartida, es solicitada por un cliente?

¿Cómo el servidor mantiene el archivo requerido?

¿Cómo AFS se asegura de que las copias en cache (de archivos) son actuales cuando estos son actualizados por varios clientes?


CI-4821, sep-dic 2005

Figura 10. Distribución de los procesos en el Andrew File System

Venus

Workstations Servers

Venus

VenusUserprogram

Network

UNIX kernel

UNIX kernel

Vice

Userprogram

Userprogram

ViceUNIX kernel

UNIX kernel

UNIX kernel


CI-4821, sep-dic 2005

Figura 11. Espacio de nombres de archivos visto por el cliente de AFS

/ (root)

tmp bin cmuvmunix. . .

bin

SharedLocal

Symboliclinks


CI-4821, sep-dic 2005

Figura 12. Intercepción de la llamada al sistema en AFS

UNIX filesystem calls

Non-local fileoperations

Workstation

Localdisk

Userprogram

UNIX kernel

Venus

UNIX file system

Venus


CI-4821, sep-dic 2005

Figura 13. Implementación de las llamadas del sistema de archivos en AFS

User process UNIX kernel Venus Net Viceopen(FileName,

mode)If FileName refers to afile in shared file space,pass the request toVenus.

Open the local file andreturn the filedescriptor to theapplication.

Check list of files inlocal cache. If notpresent or there is novalid callback promise,send a request for thefile to the Vice serverthat is custodian of thevolume containing thefile.

Place the copy of thefile in the local filesystem, enter its localname in the local cachelist and return the localname to UNIX.

Transfer a copy of thefile and a callbackpromise to theworkstation. Log thecallback promise.

read(FileDescriptor,Buffer, length)

Perform a normalUNIX read operationon the local copy.

write(FileDescriptor,Buffer, length)

Perform a normalUNIX write operationon the local copy.

close(FileDescriptor) Close the local copyand notify Venus thatthe file has been closed. If the local copy has

been changed, send acopy to the Vice serverthat is the custodian ofthe file.

Replace the filecontents and send acallback to all otherclients holdingcallbackpromises on the file.

Sistemas de Archivos DistribuidosFigura 13. Implementación de las llamadas del sistema de archivos en AFS



























Sistemas de Archivos DistribuidosFigura 13. Implementación de las llamadas del sistema de archivos en AFS


CI-4821, sep-dic 2005

Figura 13. Componentes principales del Vice Service Interface

Fetch(fid) -> attr, data Returns the attributes (status) and, optionally, the contents of fileidentified by the fid and records a callback promise on it.

Store(fid, attr, data) Updates the attributes and (optionally) the contents of a specifiedfile.

Create() -> fid Creates a new file and records a callback promise on it.Remove(fid) Deletes the specified file.SetLock(fid, mode) Sets a lock on the specified file or directory. The mode of the

lock may be shared or exclusive. Locks that are not removed expire after 30 minutes.

ReleaseLock(fid) Unlocks the specified file or directory.RemoveCallback(fid) Informs server that a Venus process has flushed a file from its

cache.BreakCallback(fid) This call is made by a Vice server to a Venus process. It cancels

the callback promise on the relevant file.



CI-4821, sep-dic 2005

Otros Aspectos

Modificaciones al kernel de UNIXOperaciones en terminos de archivo, no de file descriptor

Base de Datos de DireccionamientoCopia completa de la ubicación de archivo en el servidor

ThreadsLas tablas de contenido se mantienen en cache compartido en Venus

Cache parcial de ArchivosMantiene la consistencia en la semántica del protocolo AFS



CI-4821, sep-dic 2005

Desempeño

Su principal característica es la escalabilidad. Guardar en cache todo el archivo y el protocolo de callback reducen dramáticamente la carga en el servidor (hasta 60%, Satyanarayanan).

El descenso se le atribuye al uso de callbacks para notificar a los clientes por actualizaciones, en contra del mecanismo de timeout que usa NFS para verificar la validez de las páginas en cache de los clientes.

Wide-area support.


5. Conclusiones:: Mejoras1. NFS2. AFS3. xFS

CI-4821, sep-dic 2005

• Spritely NFS

• NQNFS

• WebNFS

• NFS 4



CI-4821, sep-dic 2005

• DFS

•Mezcla de Spritely NFS y NQNFS.



CI-4821, sep-dic 2005

Motivacion:

• Redes de Alta Velocidad como ATM y Gigabit Ethernet.

• Alta demanda de accesos a archivos distribuidos.

• Limitaciones de los sistemas centralizados.

xFS:

• Sistema de Archivos Distribuido.

• Implementa RAID.

• La responsabilidad de manejar un archivo la puede tener cualquiera de los servidores de xFS.

• Rendimiento hasta 10 veces mejor que NFS y AFS

Documents

Sistemas de Archivos Distribuidos