Tema 4: Sistemas Operativos Distribuidos

Tema 4: Sistemas Operativos Distribuidos

Sistemas de Ficheros

Enrique Soriano LS, GSYC 15 de octubre de 2015

(cc) 2015 Grupo de Sistemas y Comunicaciones. Algunos derechos reservados. Este trabajo se entrega bajo la licencia Creative Commons Reconocimiento -NoComercial - SinObraDerivada (by-nc-nd). Para obtener la licencia completa, v´ease http://creativecommons.org/licenses/by-sa/2.1/es. Tambi´en puede solicitarse a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. Las im´agenes de terceros conservan su propia licencia.

Ficheros

I Tradicionalmente: datos que persisten tras la ejecuci´on del

proceso y/o del sistema (excepci´on: ramfs), y que son

compartidos por distintos procesos y/o sistemas.

I Requisitos:

I Gran tama˜no

I Durabilidad

I Acceso concurrente

I Protecci´on

I M´as general: es una interfaz. P. ej. puede representar un

Ficheros de datos

I Estructura: fichero simple (UNIX), Resource Forks (Mac)...

I Nombre: ¿extensi´on?

Ficheros: Estructura Interna

I Bloque f´ısico → determinado por el HW (sector).

Tradicionalmente de 512 bytes, algunos fabricantes est´an

pasando a 4 Kb.

I Bloque l´ogico → determinado por el sistema de ficheros.

I Si no coinciden, empaquetamos.

I Siempre hay fragmentaci´on interna en los bloques.

I ¿Tama˜no? compromiso entre:

↑ tama˜no de bloque ⇒ ↑ fragmentaci´on

Discos

Acceso al disco:

I Secuencial: se accede registro a registro (contiguos).

I Aleatorio: se accede a cualquier registro inmediatamente.

¿Y los discos duros actuales? Caches flash, discos SSD, h´ıbridos, etc.

Discos

I Direccionamiento de bloques: CHS, LBA.

I As´ı eran:

9/17/12 upload.wikimedia.org/wikipedia/commons/0/02/Cylinder_Head_Sector.svg

1/1 upload.wikimedia.org/wikipedia/commons/0/02/Cylinder_Head_Sector.svg

Discos

I Algoritmo de planificaci´on de disco: c´omo organiza el SO las

operaciones de entrada/salida.

I El algoritmo depende totalmente del tipo de disco que usemos.

I Los cl´asicos:

I FIFO: es justo, no altera el orden de las operaciones. Lento en

discos mec´anicos.

I Shortests Seek First: no es justo, puede provocar hambruna,

desordena operaciones.

I SCAN (Ascensor): compromiso justicia/eficiencia, no provoca

Discos: RAID

I RAID: Redundant Array of Inexpensibe Disks.

I Es un caso de virtualizaci´on de almacenamiento.

Discos: RAID 0

I Striping (interleaving) por bloques.

I Sin redundancia.

I Bloques contiguos se escriben en paralelo.

9/17/12 upload.wikimedia.org/wikipedia/commons/9/9b/RAID_0.svg 1/1 upload.wikimedia.org/wikipedia/commons/9/9b/RAID_0.svg A7 A5 A3 A1 A8 A6 A4 A2

RAID 0

Disk 0 Disk 1

Discos: RAID 1

I Mirror.

I Distintas lecturas en paralelo.

9/17/12 upload.wikimedia.org/wikipedia/commons/b/b7/RAID_1.svg 1/1 upload.wikimedia.org/wikipedia/commons/b/b7/RAID_1.svg A4 A3 A2 A1 A4 A3 A2 A1

RAID 1

Disk 0 Disk 1

Discos: RAID 4

I Striping (interleaving) por bloques.

I Dedica un disco entero para la paridad.

I Se soporta el fallo de un disco.

9/17/12 upload.wikimedia.org/wikipedia/commons/a/ad/RAID_4.svg 1/1 upload.wikimedia.org/wikipedia/commons/a/ad/RAID_4.svg

RAID 4

D1 C1 B1 A1 Disk 0 D2 C2 B2 A2 Disk 1 D3 C3 B3 A3 Disk 2 Dp Cp Bp Ap Disk 3 Imagen: (cc) Wikipedia

Discos: RAID 5

I Striping (interleaving) por bloques.

I La paridad est´a distribuida por los discos.

I Se soporta el fallo de un disco.

I Soluciona el cuello de botella de RAID 4.

9/17/12 File:RAID 5.svg -‐‑ Wikipedia, the free encyclopedia

1/4 en.wikipedia.org/wiki/File:RAID_5.svg

File:RAID 5.svg

From Wikipedia, the free encyclopedia

No higher resolution available.

RAID_5.svg ​(SVG file, nominally 675 × 500 pixels, file size: 26 KB) This image rendered as PNG in other sizes: 200px, 500px, 1000px, 2000px.

This is a file from the Wikimedia Commons. Information from its description page there is shown below.

Commons is a freely licensed media file repository. You can help.

RAID AND NAS

Summary

Description English: RAID 5 with these four disks (disk 0, 1, 2, and 3) and each group of blocks (orange, yellow, green, and blue) have a distributed parity block that is distributed across the four disks, which has no consequenses for other raids

Date 31 December 2006 Source Own work

This vector image was created with Inkscape.

Author en:User:Cburnett Permission

(Reusing this file) GFDL

SAN

I SAN (Storage Area Network): proporciona almacenamiento de

bloques a trav´es de la red.

I Es un disco en red, no es un sistema de ficheros en red.

Particiones PC (BIOS)

Esquema tradicional de los PC (se est´a abandonando):

I MBR: Primer bloque del disco (512 bytes).

I Cargador primario: 440 bytes.

I Tabla de particiones primarias: 4 entradas de 16 bytes.

I Arrancable/no arrancable.

I Direcci´on del primer bloque (CHS).

I Tipo de partici´on (ntfs, linux, linux swap, plan9, ...).

I Direcci´on del ´ultimo bloque (CHS).

I Direcci´on del primer bloque (LBA).

I N´umero de bloques de la partici´on.

Particiones UEFI

GUID Partition Table (GPT) :

I Usa direcciones y tama˜nos de 64 bits.

I Primer bloque (LBA 0): legacy MBR.

I Segundo bloque (LBA 1): GPT header, con punteros para:

I Array de bloques con la tabla de particiones (empieza en LBA

2). El array tiene un tama˜no m´ınimo de 16 Kb

independientemente del tama˜no del sector f´ısico. Las entradas

en la tabla (128 bytes) continenen: tipo de particion, LBA del

primer bloque, LBA del ´ultimo bloque, atributos (read-only,

oculta, etc.), nombre de particion...

I Copia de la cabecera.

I El primer bloque usable.

I ...

I El cargador est´a en una partici´on de tipo ESP (EFI System

Vol´

umenes L´

ogicos

I Los vol´umenes l´ogicos (LV) pueden estar formados por

distintos trozos (physical extends, PE) de distintos vol´umenes

Sistemas de Ficheros

I Invenci´on del SO para ofrecernos ficheros.

I Se puede implementar de distintas formas: asignaci´on

Asignaci´

on de espacio (FS): contigua

I Un fichero ocupa una serie de bloques contiguos en disco.

I Acceso r´apido en discos de acceso secuencial.

I Rendimiento alto: un acceso para conseguir un dato

cualquiera → la entrada de directorio contiene la direcci´on de

inicio y la longitud del fichero.

I Problema: si hay asignaci´on din´amica → fragmentaci´on

externa.

I Problema: hay que saber el tama˜no m´aximo del fichero

cuando se crea.

Asignaci´

on de espacio (FS): enlazada

I Un fichero es una lista enlazada de bloques.

I Se tienen punteros al primer y al ´ultimo bloque.

I Datos por bloque = tama˜no de bloque - tama˜no de estructura.

I Ventajas:

I No hay fragmentaci´on externa.

I Tama˜nos no limitados por huecos.

I Problemas:

I Acceso aleatorio ineficaz.

I Necesitamos estructura de metadatos en cada bloque para el

enlace.

Asignaci´

on de espacio (FS): enlazada de clusters

I Cluster: agrupaci´on de bloques contiguos (e.g. 32 Kb).

I No se desperdicia tanto (1 estructura para n bloques).

I B´usqueda m´as r´apida (menos saltos).

Asignaci´

on de espacio (FS): enlazada con tabla

Tabla FAT:

I La tabla FAT reside en memoria.

I Una entrada por cluster.

I El ´ındice de la tabla es el n´umero de cluster.

I La entrada de directorio tiene la referencia a la entrada primer

cluster.

I La entrada del cluster actual referencia la entrada del

siguiente cluster.

I Mejora del acceso aleatorio: no hay que leer los clusters del

Asignaci´

on de espacio (FS): enlazada con tabla

FAT 0 0 -1 1 0 2 0 3 9 4 0 5 0 6 0 7 0 8 11 9 0 10 1 11 0 12 0 n ... MYFILE.txt First: 4 clusters: 4 9 11 1

Asignaci´

on enlazada con tabla: FAT

I Tabla FAT en memoria principal → no puede ser muy grande

→ clusters grandes → fragmentaci´on interna.

I El acceso aleatorio es m´as r´apido que en lista enlazada normal.

Ejemplo: FAT32

Reserved sectors

Fat

Region Data Region

I El sector 0 de la partici´on es el boot sector (tambi´en est´a

duplicado en el sector 6). Contiene c´odigo del cargador

secundario e informaci´on sobre el sistema de ficheros:

I No_{de sectores, 4 bytes (Max. tam. de disco: 2 Tb)} I Etiqueta del volumen.

I No_{de copias de la tabla FAT.} I Primer cluster del ra´ız.

Ejemplo: FAT32

I Entrada de directorio (32 bytes):

I Nombre del archivo, 8 Bytes.

I Extensi´on del archivo, 3 Bytes.

I Atributos del archivo, 1 Byte.

I Reservado, 10 Bytes.

I _{Hora de la ´ultima modificaci´on, 2 bytes.} I Fecha de la ´ultima modificaci´on, 2 bytes.

I Primer cluster del archivo, 4 bytes.

I Tama˜no del archivo, 4 bytes.

Asignaci´

on de espacio (FS): indexada

I Idea: se indexan los bloques de datos del fichero en un bloque

de indirecci´on.

I Bloque de indirecci´on grande → desperdicio.

I Bloque de indirecci´on peque˜no → no soporta ficheros grandes.

Asignaci´

on de espacio (FS): indexada multinivel

I Por niveles. P. ej. indirecci´on doble:

I Los bloques de ´ındice de 1er nivel apuntan a bloques de ´ındice

de 2o_nivel.

I Los bloques de ´ındice de 2o _{nivel apuntan a bloques de datos.}

I Ejemplo: bloques de 4Kb con punteros de 4 bytes.

I Problema: Para los ficheros peque˜nos, desperdiciamos.

Asignaci´

on de espacio: indexada con esquema combinado

I Algunos bloques directos de datos.

I Algunos bloques de indirecci´on simple.

I Algunos bloques de indirecci´on doble.

I ...

Ficheros en UNIX: I-NODOS

Asignaci´on indexada con esquema combinado:

Metadata (size, mode, etc.)

Direct Blocks Single Indirect Double Indirect Triple Indirect Data Data Data ... Direct Blocks Data Data Data ... Single Indirect Direct Blocks Data Data Data ... I-NODE ... ... ... ...

UNIX: Partici´

on

Boot Block

Super

Block I-Node vector Data

I Bloque de arranque (boot block): c´odigo de arranque del

sistema.

I Superbloque: tama˜no del volumen, n´umero de bloques libres,

lista de bloques libres, tama˜no del vector de i-nodos, siguiente

i-nodo libre, cierres...

I Vector de i-nodos: representaci´on de los ficheros.

UNIX: I-NODOS

I Cada fichero/directorio tiene un i-nodo asociado, definido por

un n´umero de i-nodo. El directorio ra´ız siempre tiene el

n´umero de i-nodo 2.

I La estructura se localiza en el vector indexando por el n´umero

de i-nodo.

UNIX: I-NODOS

I La estructura contiene:

I permisos

I tiempos

I acceso a datos (atime)

I modificaci´on de los datos (mtime)

I modificaci´on del i-nodo (ctime)

I tama˜no

I due˜no

I tipo

I n´umero de bloques

I contador de referencias (links)

UNIX: I-NODOS

I Un directorio relaciona un nombre con un i-nodo, en una

entrada (dentry).

I Un directorio tiene:

I Su propio i-nodo

I Bloques de datos con la lista de entradas

I Entre las entradas, tiene la entrada de . (su i-nodo) y ..

(i-nodo del padre).

I El OS tambi´en mantiene una cache de entradas de directorio

UNIX: I-NODOS

. 2 .. 2 usr 3 home 5 ... . 5 .. 2 joe 7 jane 9 ... METADATA direct-block 321 I-NODE 5

ROOT DATA BLOCK

321 METADATA direct-block 239 I-NODE 7 . 7 .. 5 test.txt 12 DATA BLOCK 239 /home/joe/test.txt ...

UNIX: I-NODOS

I Enlaces duros: es otro nombre para el fichero, la entrada de

directorio apunta al mismo i-nodo que el antiguo nombre.

I Enlaces simb´olicos: es un fichero cuyos datos contienen la ruta

Implementaci´

on de directorios

I Lineal

I Pro: simple.

I Contra: b´usqueda lineal.

I Lineal ordenada

I Pro: b´usqueda binaria.

I Contra: complica creaci´on y borrado.

I Tabla hash con desbordamiento

I Pro: mucho m´as r´apida que lineal.

I Contra: m´as complejidad.

Gesti´

on de espacio libre

I Bitmap: r´apido. Inconveniente: puede ser demasiado grande

como para tenerlo entero en memoria .P. ej. para 2TB de bloques → mapa de 512 MB.

I Lista enlazada de bloques libres: ineficiente si buscamos

varios, pero por lo general s´olo se busca uno libre.

I Agrupaciones: el primer nodo en la lista no est´a vac´ıo; tiene

enlaces a n bloques libres, los n-1 primeros vac´ıos, el ´ultimo

con n m´as. Ventaja: se pueden encontrar r´apidamente las

direcciones de n bloques libres.

I Cuenta: guarda en una lista el bloque libre y el n´umero de

Espacio de nombres

I Se “camina” (walk) por la ruta, resolviendo cada parte.

I Se pueden “pegar” ´arboles a nuestro espacio de nombres:

mount.

I Unix: un espacio de nombres para el sistema (comandomount

para listarlo).

I Plan 9: es controlable, puede haber un espacio de nombres

por proceso (comando ns para listarlo). Linux y otros han

Espacio de nombres

% 9fs marmita / 386 usr bin n marmita / 386 usr bin ... ... PUNTO DE MONTAJE FICHERO MONTADO

Im´

agenes de disco

I Un fichero que tiene dentro la estructura completa (sector por

sector) de un disco duro, CD-ROM (ISO 9660), floppy, etc.

I Utilidad: clonar sistemas, backups, crear CD/DVD, descargar

Im´

agenes de disco

I Ejemplo en Linux: crear y usar una imagen de floppy:

~$ # creo un fichero de 1,44 MB con ceros ~$ dd if=/dev/zero of=/tmp/f bs=512 count=2880 ~$ # formateo la imagen de floppy con VFAT ~$ mkfs.vfat -v -c /tmp/f

~$ # monto en el punto de montaje /mnt/floppy ~$ mount -o loop /tmp/f -t vfat /mnt/floppy ~$ # creo un fichero en el floppy

~$ touch /mnt/floppy/afile ~$ # ver el espacio de nombres ~$ mount

~$ # desmontar el volumen ~$ umount /mnt/floppy

Uniones

I Consiste en unir varios directorios en uno.

I Utilidades: compartir c´odigo fuente, agrupar binarios (/bin),

reunir ficheros para crear un backup (CD,DVD,...), distribuciones live, etc.

Uniones

I Ejemplo en Plan 9: crear una uni´on de tres directorios en el

directorio $home/union

term % bind -bc /tmp/a $home/union term % bind -bc /tmp/b $home/union

term % # en $home/union vemos los ficheros de

term % # /tmp/b, /tmp/a, y $/home/union, en ese orden term % ls $home/union

Mecanismo: Proyecci´

on en memoria

I mmap: mapea un fichero en memoria para poder acceder a los

datos del fichero como si fuese un buffer, sin usar read ni

write.

I El fichero se trae poco a poco → paginaci´on por demanda.

Sistemas de ficheros con historico (snapshots)

I Venti es un servidor de bloques en espacio de usuario,

identificados por su hash SHA-1 (20 bytes).

I Venti nunca borra los bloques.

I Fossil es un sistema de ficheros en espacio de usuario, que

puede usar bloques del disco y bloques de venti.

I Fossil tiene snapshots ef´ımeros y permanentes.

I Para crear un snapshot permanente, archiva los bloques en

FS en espacio de usuario

I En algunos sistemas, es lo normal (P. ej. Plan 9).

I En UNIX:

I VFS (Virtual File System): interfaz com´un con el kernel para

todos los FS.

I FUSE: m´odulo del kernel para implementar sistemas de

FS en espacio de usuario en UNIX

Userspace

Kernel

App App App

VFS

UFS EXT3 VFAT

FS

Cache

I El kernel mantiene una cache en RAM para los bloques.

I Es muy eficiente. P. ej. La buffer cache de 4.4BSD evita el

85 % de los accesos a disco/red para conseguir bloques.

I En ocasiones es recomendable salt´arsela (e.g. modoO DIRECT

deopen en Linux).

I Cuando el sistema se est´a quedando sin marcos de p´agina, se

suele sacrificar espacio de la cache.

I El comando y llamada al sistema sync de UNIX sincroniza la

cache con el disco y actualiza el superbloque. Se ejecuta peri´odicamente.

Cache

Tipos de cache (en general):

I Escrituras:

I S´ıncrona (write-through): evita problemas de coherencia.

I As´ıncrona (delayed write-back): incrementa el rendimiento.

I Para accesos secuenciales:

I Read-ahead.

Fallos

I Perder la integridad de los metadatos (estructuras del FS) es

peor que perder datos.

I ¿Usamos una cache write-back para los datos y/o los

metadatos?

I Al crear un fichero, ¿creamos antes el i-nodo o la entrada en

el directorio?

I Al borrar un fichero, ¿liberamos antes el i-nodo o su entrada

Fallos

Despu´es de un fallo:

I Hay programas para reparar el sistema de ficheros, e.g.fsck

en UNIX.

I Hay que recorrer los bloques de los ficheros para detectar

errores, e.g.:

I Un bloque est´a asignado a un fichero y en la lista de bloques

libres a la vez.

I Un bloque en dos ficheros a la vez.

Journaling

Ideas b´asicas:

I Las operaciones se escriben en un journal (en disco) de forma at´omica. I Una vez escritas en el journal las operaciones est´an comprometidas. I En alg´un momento las operaciones se aplicar´an en el FS.

I Si el sistema falla, al rearrancar se aplican todas las operaciones pendientes en el journal (si las hay) para recuperar la coherencia.

I Desventaja: hay que escribir los datos dos veces en el disco (pero en el journal es secuencial).

Soft Updates

Ideas b´asicas:

I La escritura de los metadatos es as´ıncrona (write-back). I El usuario siempre ve la versi´on m´as reciente (en cache). I En el disco siempre hay una versi´on coherente.

I Se establecen dependencias entre las escrituras de metadatos, que marcan el orden al que van al disco, e.g.:

I Nunca se referencia una estructura no inicializada.

I Nunca se reusa una estructura sin borrar todas las referencias a la misma.

I No se borra un puntero antiguo hasta que el nuevo est´a puesto (e.g. renombrado de un fichero).

I Tras un fallo, se puede montar el volumen inmediatamente. I Es complicado de implementar, mantener y ampliar.

Soft Updates

Ejemplo de situaci´on de rollback, dependencia c´ıclica:

I Las entradas de directorio de /A/B y de /A/C est´an en el

mismo bloque X.

I Los inodos de /A/B y de /A/C est´an en el mismo bloque Y.

I Se quieren hacer las siguientes operaciones:

1. Crear fichero /A/B, pasos:

1.1 Actualizar i-nodo (modifica Y)

1.2 Meter entrada de directorio (modifica X)

2. Borrar fichero /A/C, pasos:

2.1 Borrar entrada de directorio (modifica X)

2.2 Marcar i-nodo como libre (modifica Y)

I No se puede escribir en disco el bloque Y antes que el bloque

X, ni viceversa.

I Hay que deshacer una operaci´on, escribir los bloques,

Sistemas de ficheros en red

I Permite compartir ficheros a trav´es de la red siguiendo un

esquema cliente/servidor.

I El cliente y el servidor deben hablar un protocolo de sistema

de ficheros.

I Protocolos: NFS, CIFS/SMB, WebDAV, 9P, AFP, ...

I NAS (Network-Attached Storage): HW especializado en servir

Sistemas de ficheros en red

I Stateless

I Sencillo.

I Operaciones autocontenidas.

I Los handles que da el servidor tienen que ser ´unicos (eg. fs id

+ inodo + versi´on).

I No requiere recuperaci´on tras un fallo.

I El servidor se puede reemplazar.

I Stateful

I Sesiones / estado permanente.

I El servidor puede olvidar los handles despu´es de una sesi´on.

I Fallo del servidor → recuperar del estado o abortar.

I ¿Cache coherente? ¿Locking/ Leases? ¿Callbacks?

Sem´

anticas de compartici´

on de ficheros

Las m´as comunes:

I Sem´antica UNIX (Strong Consistency).

I Sem´antica de sesi´on.

I Ficheros inmutables.

I Transacciones.

NFS

I Varias versiones diferentes.

I Hasta NFSv3 era stateless:

I File handles opacos, elegidos por el servidor.

I No hay open ni close.

I Problemas con locking, coherencia de cache, etc.

I NFSv4: stateful, RPCs compuestas, etc.

I Muy complejo:

ACCESS, BACKCHANNEL CTL, BIND CONN TO SESSION, CLOSE, COMMIT, CREATE, CREATE SESSION, DELEGPURGE, DELEGRETURN, DESTROY CLIENTID, DESTROY SESSION, EXCHANGE ID, FREE STATEID, GETATTR, GETDEVICEINFO, GETDEVICELIST, GETFH, GET DIR DELEGATION, LAYOUTCOMMIT, LAYOUTGET, LAYOUTRETURN, LINK, LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, OPENATTR, OPEN CONFIRM, OPEN DOWNGRADE, PUTFH, PUTPUBFH, PUTROOTFH, READ, READDIR, READLINK, RECLAIM COMPLETE, RELEASE LOCKOWNER, REMOVE, RENAME, RENEW, RESTOREFH, SAVEFH, SECINFO, SECINFO NO NAME, SEQUENCE, SETATTR, SET CLIENTID, SET CLIENTID CONFIRM, SET SSV, TEST STATEID, VERIFY, WANT DELEGATION, WRITE...

UNIX + NFS

Userspace

Kernel

App App App

VFS

UFS EXT3 VFAT _clientNFS Client

Userspace

Kernel

App App App

VFS

UFS

File Server

NFS server

system calls system calls

network NFS RPC

9P

I Stateful: el servidor mantiene el estado de la conexi´on.

I Stateful: posibilita la exportaci´on de ficheros sint´eticos.

I Sencillo: s´olo 13 RPCs.

I Totalmente integrado con el SO: el kernel de Plan 9 es un

9P

Userspace Kernel FS FS App #M mount driver Userspace Kernel FS network 9P 9P 9P system calls FS 9P 9P #p proc ... cons#c ... 9P* 9P* 9P*

9P*: Within the kernel, 9P is implemented by procedure calls to the various kernel device

9P: RPCs

I size[4] Tversion tag[2] msize[4] version[s] size[4] Rversion tag[2] msize[4] version[s]

Acuerda la versi´on del protocolo y comienza una nueva sesi´on. I size[4] Tauth tag[2] afid[4] uname[s] aname[s]

size[4] Rauth tag[2] aqid[13] Autenticaci´on (externa a trav´es de P9SK1). I size[4] Rerror tag[2] ename[s]

Error para todos los tipos de peticiones. I size[4] Tflush tag[2] oldtag[2]

size[4] Rflush tag[2]

9P: RPCs

I size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s] size[4] Rattach tag[2] qid[13]

El cliente se ata al ra´ız del sistema de ficheros. A partir de este momento se referir´a a ´el con el FID. El servidor responde con un identificador ´unico para el ra´ız QID (versi´on, tipo y path).

I size[4] Twalk tag[2] fid[4] newfid[4] nwname[2] nwname*(wname[s]) size[4] Rwalk tag[2] nwqid[2] nwqid*(wqid[13])

Resuelve un path, que ser´a referido con el FID newfid. Si no se pueden atravesar todos los nombres, newfid ser´a fid. El servidor devuelve la lista de QIDs de los nombres que se han podido atravesar.

9P: RPCs

I size[4] Topen tag[2] fid[4] mode[1] size[4] Ropen tag[2] qid[13] iounit[4]

I size[4] Tcreate tag[2] fid[4] name[s] perm[4] mode[1] size[4] Rcreate tag[2] qid[13] iounit[4]

I size[4] Tread tag[2] fid[4] offset[8] count[4] size[4] Rread tag[2] count[4] data[count]

I size[4] Twrite tag[2] fid[4] offset[8] count[4] data[count] size[4] Rwrite tag[2] count[4]

9P: RPCs

I size[4] Tremove tag[2] fid[4] size[4] Rremove tag[2] I size[4] Tstat tag[2] fid[4]

size[4] Rstat tag[2] stat[n]

I size[4] Twstat tag[2] fid[4] stat[n] size[4] Rwstat tag[2]

I size[4] Tclunk tag[2] fid[4] size[4] Rclunk tag[2]

9P: RPCs

Figure 1: Styx dialog between a client (left) and a server (rigth).

Time flows from the top to the bottom. The client depicted on the left performs a sequence of file op-erations or system calls (shown bold) that result in the Styx conversation shown. For the server, shown on the right, we show the actions resulting from the requests.

The part before the first dashed line introduces the client to the server. An attach transaction permits the client to define a fid (15 in the figure) that corre-sponds to the root of the file tree in the server. Most requests carry a fid to indicate the file involved in the request. In this case, several of the following requests mention the fid 15 just defined.

The next part (up to the next dashed line) corre-sponds to a client accessing the directory entry for file /a/b/cin the server. The walk transaction proposes

a new fid (16 in the figure), which starts as a clone of the fid mentioned (15 in the figure). Furthermore, this request walks that new fid to a path relative to its original position in the server’s file tree. In this case, fid 16 points to the file /a/b/c within the server once the walk transaction completes. At this point, a stat request asks the server for metadata (directory entry) for the file identified by the fid 16. Finally, the client issues a clunk request when it no longer wants to use a particular fid, to let the server forget about it and release any resource used on its behalf.

The part in the figure below the last dashed line corresponds to a client reading a file. First, a walk request defines a new fid (16 again) and points it to the file of interest, /a/b/c in this case. Now, the open transaction opens the fid for the mode specified in the request (not shown). After receiving the reply, the client issues read requests (and the server replies with data) for the offsets and number of bytes desired. Usually, the series of read transactions is completed by a last one, which is used by the server to inform the client that there is no more data to be read past the offset requested; this is the end-of-file indication. At this point, the client probably closes the file, and a clunk transaction releases (and closes) the fid.

3 Accessing Files through

Poor-latency Links

Using Styx means that multiple RPCs are needed to retrieve or update a single file. Indeed, the previously shown dialog is not too different from the one that might be spoken by better known protocols like NFS version 3.

The last two parts of figure 1 are a realistic example corresponding to the execution of ls or lc to list the contents of a directory. It is not unusual for a client program that is going to read a file or a directory to call stat before actually reading the file, for example, to check the file for access or to retrieve some meta-data. Executing the command lc at a (remotely) mounted directory would make things even worse, because the shell tries to locate the programs lc, ls, 4

Otros tipos de sistemas de ficheros en red

I Distributed FS (r´eplicas distribuidas).

I Distributed version control systems.

Distributed FS (r´

eplicas)

I Los nodos tienen una r´eplica (on-disk cache) del ´arbol de

ficheros.

I Finalidad: trabajar desconectado.

I Hay que resolver conflictos a la hora de sincronizar las r´eplicas.

Distributed version control systems

I Sistemas que sirven para mantener copias de un ´arbol con

control de versiones.

I Guarda las distintas versiones de los ficheros, gestiona

commits, puede crear distintas ramas, etc.

I Finalidad: principalmente, coordinar cambios en el c´odigo

fuente de un proyecto de forma distribuida.

I Tambi´en hay que resolver conflictos a la hora de sincronizar

las r´eplicas.

Cluster FS

I Los bloques de los ficheros est´an distribuidos en un cluster.

I Finalidad: file striping.

I Ejemplos: Google FS, Hadoop Distributed File System

Caso: Google FS

I Tolera fallos de los servidores.

I Optimizado para append y lecturas.

I Escalabilidad: miles de nodos por cluster, petabytes de datos.

I No muchos ficheros, pero ficheros muy grandes.

I Sacrifican latencia por throughput.

I Coherencia relajada: las r´eplicas pueden diferir en ciertas

partes. Las aplicaciones deben lidiar con esto.

Caso: Google FS

Caso: Google FS

Master:

I ¿ ´Unico punto de fallo?

I Shadow Masters.

I ¿Cuello de botella? No, s´olo mantiene el control, no hace

Caso: Google FS

Master:

I Almacena s´olo los metadatos: todo en memoria, log en disco para asegurar coherencia.

I Las actualizaciones de metadatos son at´omicas. I Controla el espacio de nombres.

I Hace polling para localizar los chunks, rebalancear y controlar ca´ıdas de chunk-servers.

I Crea nuevos chunks.

I Ordena la replicaci´on de chunks en chunk-servers (3+). I Controla los leases de las r´eplicas primarias.

I Controla los locks sobre ficheros/directorios. I Realiza la recolecci´on de basura.

Caso: Google FS

Cliente:

I No tienen cache de datos.

I Tiene cache (con tiempo de caducidad) de metadatos

(chunk-handles, etc.).

Caso: Google FS

Mutaci´on: Write (poco usada)

Figure extracted from the original GFS paper (SOSP 2003).

1. El cliente pide al Master la lista de r´eplicas y el primario.

2. El Master elige un primario si no hay. El primario adquiere un lease. El cliente cachea la respuesta del Master para futuras peticiones. Esos datos pueden caducar.

3. El cliente env´ıa los datos a todas las r´eplicas. Las r´eplicas guardan los datos en sus buffers.

4. El cliente env´ıa una petici´on write al primario.

5. El primario serializa las distintas mutaciones que recibe y las aplica al chunk. Va enviando la secuencia al resto de r´eplicas.

6. Cada r´eplica aplica las modificaciones en el orden que dicta el primario. Al aplicar un cambio, notifica al primario.

7. Tras recibir las notificaciones de las r´eplicas para el write, se responde al cliente. Si hay error en las r´eplicas, el cliente puede reintentar (desde el paso 3 o desde el paso 1). Despu´es del fallo habr´a zonas de la r´eplica fallida incoherentes → sem´antica relajada (weak).

Caso: Google FS

Mutaci´on: Atomic Record Append (muy usada)

1. El cliente env´ıa los datos del append a todas las r´eplicas. 2. El cliente ordena el atomic-append al primario. 3. El primario comprueba si se desborda el ´ultimo chunk.

I Si se desborda, se rellena con un hueco el chunk y se le indica al cliente que la operaci´on se debe realizar en el siguiente chunk (el Master lo crear´a) → Fragmentaci´on interna. El tama˜no de un append est´a limitado para evitar mucha fragmentaci´on (1/4 de tama˜no de chunk).

I _{Si no se desborda, se serializa la escritura en el chunk como en un write.}

4. Si falla alguna r´eplica secundaria,se repite la operaci´on append

I El offset se avanza de todas formas en las r´eplicas que fallaron: todos los chunks tienen el mismo tama˜no).

I _{Los datos del append aparecen repetidos en las r´eplicas que no fallaron →}

Bibliograf´ıa

I A. S. Tanenbaum. Operating Systems, design and implementaiton. Pearson Prentice Hill.

I A. S. Tanenbaum. Distributed Systems. Pearson Prentice Hill.

I A. S. Tanenbaum. Modern Operating Systems. Pearson Prentice Hill.

I A. Silberschatz. Operating Systems. Wiley.

I Plan 9 User Manual, Section 5, Introduction (man 5 0intro).