Qui invece ammetto anche dei cicli, e posso quindi puntare ovunque nel FS. Comodo per fare ricerche, ma occorre comunque stare attenti che le ricerche non si perdano in un ciclo.

Tutto quanto detto in questa Lezione 3 NON È l'argomento "protezione dei files", bensì una specie di introduzione. E allora, che lo scrivo a fare?:)

Ecco allora che nasce spontanea la struttura ad albero, in cui il primo nodo è la radice del filesystem, e ogni nodo rappresenta un gruppo di files.

Prendendo a modello la biblioteca, vorremmo poter organizzare i nostri files secondo un qualche criterio che più ci aggrada, ovvero per argomento. E ogni argomento sarebbe bello poterlo dividere in sottoargomenti e così via.

Torna alla pagina di Sistemi Operativi

Tutti sti blocchi devono rimanere sul disco, così che quando spengo e riaccendo il computer non scompare la roba:)

Ma ci sono anche altre cose che, invece, devono risiedere in memoria centrale:

• la tabella delle partizioni
• i descrittori delle dir
• la tabella dei files aperti dal sistema
• la tabella dei files aperti da ogni processo
• la tabella di montaggio del FS

Per aprire un file, si usa la primitiva open. Viene eseguita nello spazio utente, si controlla il percorso e i permessi nello spazio kernel, e poi si accede al blocco corretto.

La open è una funzione che restituisce un indice. Questo è l'indice di una posizione nella tabella dei files aperti del processo. A sua volta, quella posizione nella tabella rimanda ad un'altra posizione, stavolta nella tabella dei files aperti dal SO.

Ogni processo ha la sua tabella, che è nello spazio privato del processo e nessuno la può tangere. Se più processi hanno lo stesso files aperto, avremo semplicemente che la voce relativa a quel file nella tabella dei processi porterà alla stessa voce nella tabella del SO.

Tutte le primitive per agire sul file vengono passate al SO indicandogli l'indice del file che voglio utilizzare. Il SO prima controlla nella tabella del processo, poi risale alla tabella del SO, e da qui sa risalire al blocco giusto nel disco.

FS virtuali

Il FS virtuale è realizzato tramite un'interfaccia che dal pdv logico sta sotto all'interfaccia del FS. Il VFS pensa a gestire i FS locali e quelli remoti in modo del tutto trasparente rispetto a chi lo utilizza.

Un FS distribuito appare come un unico ed identico FS da qualsiasi macchina io usi per accedervi. Se invece ogni macchina ha sì l'accesso ad un FS remoto tramite la rete, non ho un vero FS distribuito.

Perché? Il motivo è che ogni macchina avrà, nel complesso, un FS diverso. Infatti

• o la porzione locale del FS è diversa per ogni macchina;
• o il FS remoto è montato in punti diversi su diverse macchine;
• o una macchina ha montati certi FS e un'altra ne ha altri

e quindi NON È un vero VFS

Realizzazione delle dir

Una dir è un elenco di descrittori di files, i quali possono essere, a loro volta, files o altre dir. Come realizzo questo elenco?

Struttura a lista

C'è una lista, e ogni elemento ha un puntatore all'elemento dopo. Semplice, ed efficiente quando l'elenco è ordinato e vi accedo in ordine.

Ma se devo cercare un elemento a caso, in generale il tempo di scansione è O(n), perché devo passare da tutti gli elementi.

Come posso ottimizzare un po'?

• mantenendo la lista ordinata: se cerco un file che inizia per D, e dopo la C trovo la E, sapendo che la lista è sicuramente ordinata allora so per certo che il file che cerco non esiste. Insomma, in media faccio solamente n/2 accessi
• usando una cache per velocizzare la faccenda
• usando un albero binario, e se è bilanciato, tanto meglio.

Struttura a tabella di hash

Occorre una funzione di hash adatta, che comprima, dia poche collisioni e distribuisca bene i files. Vedi altrove per qualche parola in più sulle funzioni di hash.

Lezione 3: Realizzazione dei files - Gestione dell'astrazione dei file

Il file in realtà non esiste. È un entità che appare solo quando la guardo in un certo modo, ovvero quando la guardo tramite il FS (visione logica) o dal pdv fisico.

Visione logica

Come già dicemmo, il file è una sequenza di elementi omogenei in numero non limitato a priori.

Che tipo di elementi? Quelli che l'applicazione vuole, e si chiamano record logici. Quando creo il file, dichiaro anche il tipo base, e quindi so quanto occupa sul disco in base alla dimensione del record logico e al numero di record logici che il file contiene.

Visione fisica

Il file è una sequenza ordinata di blocchi. Per ogni file, il FS deve sapere da che blocco iniziare, dove finire, e in che ordine essi vanno presentati.

Si vede subito che la visione fisica va mappata nella visione logica, e al solito posso farlo in diversi modi.

1 record logico = 1 blocco fisico

Va bene, ma qui dipende dalle dimensioni reciproche.

Se il record logico è più piccolo del blocco fisico, allora spreco spazio in ogni blocco. Al contrario, se il record logico è più grosso del blocco fisico, non ci sta.

Se ci pensiamo, non è logico forzare la dimensioni dei record logici sulla base del blocco fisico.

+ record logici in 1 blocco fisico

Metto record in un blocco finchè c'è spazio. Ma c'è sempre il solito vincolo illogico.

Byte Stream

Un'applicazione può usare tutti i record logici che vuole, ma alla fin fine, dal pdv di una macchina, essi altro non sono che delle sequenze di 0 ed 1, organizzate in parole.

E allora, la cosa migliore da fare è vedere tutti i record logici per quello che sono, ovvero sequenze di byte, e scriverli uno dopo l'altro in un byte stream, cioè un flusso di byte.

Il blocco quindi avrà le dimensioni che voglio, che tanto scriverò sempre tutti i byte in fila, uno dietro l'altro, fregandomene del record logico. Ci deve infatti pensare l'appli a interpretare i byte come vuole lei.

Quindi, posso fregarmene della dimensione del record logico, perché tanto scrivo sempre e solo dei byte in fila.

Gli sprechi sono ridotti al minimo. Ho sprechi solo quando:

• scrivo 1 o più record logici, la cui dimensione complessiva è inferiore a quella di un blocco fisico
• ho n record logici, divisi in m blocchi, e l'ultimo blocco non è usato del tutto

Ma si tratta di ben poca roba. Quello che faccio è dividere il bytestream in tot parti, ciascuna grossa come un blocco fisico, e via.

Che cosa succede con la lettura? Il FS opera sui blocchi, ma l'appli opera sui record logici.

L'idea qui è quella di avere una finestra, ed è l'appli a dire al SO quanto essa è grande. La finestra si sposta sul bytestream, passando da un record logico all'altro.

Il FS allora non deve fare altro che tenere in memoria i blocchi che stanno sotto la finestra corrente, e dare i byte che stanno sotto alla finestra all'appli, e poi ci pensa l'appli. Ecco come si realizza l'astrazione.

Idem per la scrittura: scrivo i blocchi che stanno sotto alla finestra, e la finestra al solito ha le dimensioni che l'appli preferisce.

La finestra si sposta sul filesystem di L byte alla volta, dove L è la dimensione del record logico.

Il posizionamento avviene tramite un rapido calcolo che, data la dimensione del blocco, della finestra, e il numero dell'elemento che voglio, sa risalire a quali blocchi caricare in memoria.

Quando chiudo un file, scrivo le modifiche su disco, e levo tutte le voci necessarie dalle tabelle del processo e del SO.

In genere si decide di scrivere le modifiche ad un blocco non appena esso viene riempito, così da minimizzare l'impatto di eventuali guasti a metà scrittura.

Torna alla pagina di Sistemi Operativi

Warning!
Tutto quanto detto in questa Lezione 3 NON È l'argomento "protezione dei files", bensì una specie di introduzione. E allora, che lo scrivo a fare?

Nei sistemi multiutente vorrei poter condividere files, così che ogni utente possa usarli, oppure rendere possibile la collaborazione, ovvero avere più utenti che lavorano contemporaneamente allo stesso file. Certo, c'è la solita storia degli accessi compatibili in lettura e scrittura e bla bla BLA.

Nei sistemi multiutente devo autenticare utenti e gruppi, così so che privilegi accordare loro. Per esempio, i files possono portarsi dietro degli attributi che mi dicono chi può leggerli, chi può scriverli e simili amenità.

L'idea è quella di implementare un concetto, detto dominio di protezione, che non abbiamo ancora visto, ma che vedremo.

Si possono anche condividere files remoti, tramite sistemi come ftp, http, fs di rete o ancora fs distribuiti.

Con ftp e http, mi connetto al server, scarico il mio files, lo palpugno e poi lo reuploado al server.

Con un fs di rete, invece, quel fs è montato sul mio fs generale => lavoro direttamente in remoto, non devo stare lì a copiare e ricopiare. Certo saranno più lente le operazioni perché devono passare per la rete, ma se ho files grossi risparmio il tempo di download e upload ad ogni modifica.

Per mantenere la coerenza (vedi qui dentro), ho diverse scelte:

• modifiche visibili immediatamente dopo 1 modifica
• modifiche visibili solo dopo che chiudo il file
• modifiche visibili solo in una sessione successiva
• immutabilità dei files condivisi

Vediamo di spiegarci.

Nel primo caso, se l'utente A modifica il file F, l'altro utente B lo vede subito. Nel secondo caso, invece l'utente B vede le modifiche solo dopo che A ha chiuso il file. Nel terzo caso, infine, qualsiasi cosa abbia fatto A al file, B deve chiudere F e poi riaprirlo per ottenere le nuove modifiche.

Se accadono guasti, può insorgere dell'incoerenza nei miei files. Introduciamo allora il concetto di stato del FS, e più in là ci verrà spiegato.

Per quanto riguarda la protezione, devo impedire accessi improprio. Il già citato dominio di protezione verrà implementato in qualche modo, così che ogni utente potrà autenticarsi, e ricevere una lista di permessi da applicare in giro per il FS.

Il controllo dell'accesso lo posso fare in molti modi.

FS: Struttura e realizzazione

L'obiettivo del FS è di gestire omogeneamente le risorse informative e fisiche del sistema di elaborazione, e tutte ste risorse devono essere viste come flussi di informazioni elementari.

Diciamo risorse sia informative che fisiche, perché vogliamo trattare allo stesso modo i files e le varie periferiche. Ad esempio, la tastiera è una periferica da cui leggo caratteri, uno alla volta, per esempio. Allo stesso modo, una scheda audio è una periferica in cui scrivo campioni sonori, e così via.

Ogni periferica e ogni files ha il suo tipo di dato elementare. La tastiera usa il carattere, la scheda video i pixel (per esempio), il file dario.txt degl interi. Noi vogliamo che il FS mostri tutte queste risorse come un flusso delle info elementari di cui sono costituite.

Qui noi ci focalizzeremo sulle risorse informative (i files), piuttosto che su quelle fisiche.

Supporto fisico del FS

Posso mettere FS ovunque, ma qui parliamo di dischi di memoria secondaria, che sono diffusi e noti.

Abbiamo già visto che a basso livello ci sono settori e tracce e cilindri. È ovvio che non possiamo andare a cercare la roba per il disco in base a queste informazioni, che hanno ben poco di umano. E infatti, qui sopra dicevamo che vogliamo offrire flussi di tipi base agli utenti, e non cilindri e settori.

E allora occorre astrarre: da cilindri e settori passiamo a blocchi, e dai blocchi passeremo ai files e alla loro organizzazione logica nel FS. È proprio il FS che realizza questa astrazione.

Ad esempio, noi vogliamo che i dati tra il settore 47 e l'85 della traccia 2 siano il file testo.txt, oppure - visto che vogliamo trattarli allo stesso modo - che i caratteri che provengono dalla tastiera siano disponibili nel file /dev/keyboard.

Strutture del software che gestisce il FS

Guarda come gestisce bene i dischi!

È composto da 4 livelli diversi

1. gestione fisica della periferica = è il driver di periferica delle lezioni precedenti
2. FS di base: legge e scrive blocchi fisici
3. modulo di organizzazione dei files: mappatura tra files e blocchi presi in ordine
4. FS logico: dir, nomi files, permessi et similia

Il punto 1 è il driver di periferica, diviso in dipendente ed indipendente dall HW.

I punti 2, 3 e 4 sono invece il FS vero e proprio.

Ma vediamo un po' sti blocchi. Sul disco, ho questi tipi di blocchi:

• blocco di controllo del boot
• blocco di controllo della partizione
• directories
• blocchi di controllo dei files

I blocchi che descrivono i files devono contenere le info relative ai files:

• permessi
• date del file (ultimo accesso, ultima scrittura, creazione)
• proprietario, gruppo, eventuale Access Control List
• dimensione
• lista ordinata dei blocchi che costituiscono il file

(:title SO - Lezione del 29 aprile 2008:)

 :: SO - Lezione del 29 aprile 2008 ::

Struttura del FS - Le directory

Dopo aver parlato dei files, parliamo della seconda struttura tipica del FS, cioè le directory. Non mi piace la parola direttorio, quindi non la uso. Il prof la pensa diversamente, tuttavia...

Servono per organizzare in modo logico il disco: posizionare i files all'interno di dir server per sistemarli secondo un qualche criterio.

Directory ad 1 livello

Tutto è nella stessa directory. Immaginate il casino. Posso ancora dividere le cose per utente, con permessi etc. ma non è molto comodo perché devo avere nomi univochi e non posso separare il materiale in base all'utilizzo

2 livelli

C'è una dir per utente, ed è quindi adatto a SO multiutente. Sono quindi ammessi files omonimi, la ricerca è efficiente, però rimane ancora la faccenda che ogni utente vede tutti i suoi files nello stesso calderone.

Ma noi come lo vogliamo, sto FS?

Prendendo a modello la biblioteca, vorremmo poter organizzare i nostri files secondo un qualche criterio che più ci aggrada, ovvero per argomento. E ogni argomento sarebbe bello poterlo dividere in sottoargomenti e cosù via.

Struttura ad albero

Ecco allora che nasce spontanea la struttra ad albero, in cui il primo nodo è la radice del filesystem, e ogni nodo rappresenta un gruppo di files.

Un gruppo di file può contenere files o altre dir, e così via. Se un file appartiene ad un gruppo, cioè ad un sottinsieme, non può appartenere a nessun altro gruppo.

Per individuare i files, dobbiamo conoscere, oltre al loro nome, anche la posizione logica all'interno del FS, cioè la sequenza di dir, a partire dalla radice, che dovrei percorrere per giungere a quel file.

Nella struttura a 2 livelli, ogni utente ha la sua dir. Qui non sono obbligato ad avere una dir per utente, anche se in genere lo si fa lo stesso perché alla fine è comodo.

Ho la possibilità di avere files omonimi, perché il nome intero del files comprende anche il percorso, e finché il percorso logico è diverso, allora van bene anche le omonimie. Posso cercare in modo efficiente, posso spostare qua e là un file, posso raggruppare secondo i criteri che preferisco, e posso mettere facilmente gruppi in condivisione. Very good.

Directory a grafo aciclico

L'unico svantaggio dell'albero è che non posso dare nomi diversi allo stesso file: infatti, i gruppi sono un partizionamento dell'insieme dei files, e pertanto sono sottinsiemi disgiunti.

Esiste allora la directory a grafo aciclico, in cui un unico oggetto può essere visto con 2 nomi diversi. Eg, /home/dario/testo.txt è la stessa roba di /usr/local/parole.doc, volendo.

In questo modo condividere files è molto più semplice e naturale che doverli ricopiare in una dir apposita.

Si dice "grafo aciclico" perché ad un certo punto questo gioco di rimandi deve finire.

Directory a grafo generale

Qui invece ammetto anche dei cicli, e posso quindi puntare ovunque nel S. Comodo per fare ricerche, ma occorre comunque stare attenti che le ricerche non si perdano in un ciclo.

Memorie di massa a dischi multipli

Ogni disco ha il FS in proprio. Ma come li vede l'utente?

L'approccio semplice è quello di rendere visibile all'utente la divisione in dischi. Ovvero, all'utente è reso noto che quel FS appartiene a quel disco e quell'altro FS a quell'altro disco. È l'approccio di uindoz, per intenderci, in cui abbiamo i drive D:\, E:\ etc.

Ma dal pdv logico è irrazionale: che gliene frega all'utente dei dischi? Dovrebbe esserci un FS unico, astratto rispetto alla fisicità del computer. Avere i dischi visibili è comodo solo a chi scrive il SO.

Dischi grossi

C'è un FSone gigantesco, con conseguente poca efficienza, e soprattutto, pericolo. Infatti, se per qualche motivo il FS si danneggia, tutto il disco potrebbe diventare poco usabile, o addirittura per niente utilizzabile.

La mossa astuta allora è dividere il disco in partizioni, e su ogni partizione mettere un FS diverso, e separare in qualche modo intelligente il materiale in queste partizioni. Così facendo, se il FS di una partizione si danneggia, questo danno non pregiudica i FS delle altre partizioni.

Ad esempio, se in una partizione metto i dati e nell'altra le applicazioni, un danno al FS delle applicazioni non pregiudica i miei dati, ben più importanti. Infatti uinzoz non fa così, sarebbe troppo intelligente.

Un volume logico è l'astrazione di una partizione che sta però su più dischi. Alcuni SO forniscono tale astrazione, e ci pensano poi loro a mandare le richieste al posto giusto.

Se ho più dischi fisici, e voglio vederli in un unico FS, allora alcuni nodi del FS vengono detti punti di montaggio: in questi punti viene "collegata" la dir radice del FS di un'altra partizione, così che se parto dal FS generale, arrivo a quel punto e automagicamente passo nel FS dell'altro disco (o dell'altra partizione). E questa è cosa buona e giusta.

Lezione 3 - Condivisione dei files & protezione

'''Tutto quanto detto in questa lezione NON È l'argomento "protezione dei files", bensì una specie di introduzione. E allora, che lo scrivo a fare?