Vai alla Home Page About me Courseware Federica Living Library Federica Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

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.

Un file system distribuito (DFS)

Un file system distribuito è una realizzazione distribuita del classico modello di file system.

Estensione dello stesso tipo di condivisione al caso in cui i file sono distribuiti tra i siti di un sistema distribuito.


Un primo esempio: FTP

L’utente ha a disposizione un insieme di operazioni sui file remoti che e’ un sottoinseme delle operazioni sui file locali.

L’utente deve essere a conoscenza della locazione dei file.

Operazioni esplicite di upload e download (put e get).

Coerenza di copie locali e remote a carico dell’utente.

Condivisione tramite “ftp anonymous”.


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.

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.

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 quinto problema

La semantica della condivisione

Quando due o piu’ utenti accedono allo stesso file è necessario definire la semantica (cioè definire quale comportamento è errato e quale è corretto).

Esempio: consistenza sequenziale (semantica UNIX):

  • quando una read segue una write, la read deve restituire i dati appena scritti;
  • facile da realizzare nei monoprocessori.

Cosa puo’ accadere in un sistema distribuito

Molto difficile e dispendioso realizzare una consistenza sequenziale in un ambiente distribuito.

Rilassare la semantica.

Accontentarsi di una semantica di sessione:

  • i  cambiamenti sono visibili subito al processo che li ha fatti;
  • sono visibili agli altri processi quando il file viene chiuso.

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).

I materiali di supporto della lezione

Silberschatz , Galvin, Gagne – Sistemi Operativi 8a ed. Capitolo 16

Tanenbaum – Moderni sistemi operativi 3a ed. Capitolo 8

Deitel, Deitel, Choffnes - Sistemi operativi 3a ed. Capitoli 13 e 14

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion