Marco Lapegna » 18.I Sistemi Operativi distribuiti - parte quinta

Caratteristiche di un file system

Dati persistenti (i file).
Spazio dei nomi gerarchico (o piatto) visibile a tutti i processi.
API per accedere e modificare i dati (open, close, read,…).
Condivisione tra i processi attraverso meccanismi di controllo degli accessi (es. rwxrwxrwx di Unix).
Accesso concorrente:

• sicuramente in lettura;
• protocollo lettori/scrittori in aggiornamento.

Possibilità di montaggio di altri file system.

E’ una implementazione di una memoria permanente che consente la condivisone dei dati tra gli utenti.

Architettura generale di un DFS

Problematiche di progettazione

Nella progettazione di un file system distribuito bisogna affrontare molte problematiche:

• localizzazione dei file (quando richiesti, i file si devono spostare o rimanere sul server?)
• visione del file system (unica per tutti i client oppure no?)
• trasparenza (cosa deve sapere l’utente?)
• caching (come gestire la cache?)
• semantica (se 2 utenti modificano un file, quando devono essere visibili le modifiche?)
• fault tolerance (se un server diventa inaccessibile che succede?)

Un primo problema di progettazione

Confronto

Modello upload/download
Vantaggi:

• semplicità (facile implementare get e put);
• efficienza (l’accesso avviene localmente).

Svantaggi:

• possibile incorenza (accesso concorrente al file);
• spreco di risorse (se serve solo un pezzo del file).

Modello ad accesso remoto
Vantaggi:

• assenza di incoerenza (1 sola copia del file);
• poca memoria richiesta (non ci sono duplicati).

Svantaggi: inefficienza (sincronizzazione degli accessi e traffico di rete).

Un secondo problema

Visione uniforme delle directory vs visione non uniforme.

Confronto

Stessa visione

• Ambiente familiare
• Meno flessibile
• Necessità di una directory radice

Visione differente

• Più facile e flessibile
• Ambiente che può “disorientare” gli utenti
• Scelta più comune nei DFS

Deve esistere una directory radice?

Un terzo problema

Trasparenza

Di accesso (la modalità di accesso deve essere indipendente dalla posizione fisica).

Di posizione (la posizione fisica del file non deve essere nota all’utente).

Di replicazione (l’utente non deve sapere quante copie del file esistono).

Di migrazione (l’utente non deve sapere se il file viene spostato da un server ad un altro).

Non tutti sono facili da realizzare (es. trasparenza di migrazione).

Schemi di nominazione

I nomi dei file sono scelti come combinazione del nome dell’host e nome locale del file.

• Es: server1:/dir/nomefile oppure /server1/dir/nomefile.
• Garanzia di unico nome in tutto il file system.

Implementazioni

Mount di directory remote (es. NFS)

Integrazione delle varie directory locali (es. AFS)

Un quarto problema: il caching

Quando un utente richiede un file, il server su cui si trova e’ identificato dallo schema di nominazione.

I dati sono trasferiti, ad esempio, mediante RPC.

Per migliorare le prestazioni e’ necessario ridurre il traffico di rete generato da questi trasferimenti → Caching dei file

• Se i dati non sono in cache: vengono trasferiti dal server.
• Se sono in cache: gli accessi avvengono sulla copia in cache.

Osservazione

La gestione di una cache per un file system distribuito e' molto simile ad una Memoria virtuale di rete.

Coerenza della cache

Il problema principale nell’uso della cache è che, per sua natura, i file sono condivisi tra molti utenti

Possibilità di incoerenza delle cache (analogo al problema delle corse critiche).

Metodo iniziato dal client: il client periodicamente controlla se la sua copia è coerente con quella del server.

Metodo iniziato dal server: il server tiene traccia dei file aperti con le rispettive modalità e interviene se riscontra che uno stesso file è aperto 2 volte in modalita’ conflittuali (uso del protocollo lettore/scrittore).

Confronto

Metodo iniziato dal client

• Con che frequenza il client verifica la coerenza?
• Es. ad ogni accesso, ad intervalli regolari, all’apertura del file.

Metodo iniziato dal server
Come reagisce il server?

• Impone ai client di invalidare le copie in cache.
• Impone ai client di eliminare i file nelle cache dopo il loro uso.
• Ritarda l’apertura dei file.

In entrambi i casi le scelte determinano la semantica e l’efficienza.

Un modello alternativo

Se la semantica di sessione appare “superficiale” e può dare luogo ad inconsistenze, si può:

• Impiegare il modello download/upload;
• Il server pone un lock ad un file inviato ad un client;
• Un successivo client aspetta il rilascio del lock.

Un sesto problema

Se un server diventa inaccessibile che succede?

Una soluzione è la replicazione dei file (più copie disponibili in vari file server).
I guasti sono indipendenti → miglioramento della fault tolerance.

Vincoli

• Aggiornamento: una modifica deve propagarsi su tutte le copie.
• Trasparenza: l’esistenza di repliche deve essere invisibile all’utente (la differenza è solo nello schema di nominazione).