File System. Capitolo 13

Транскрипт

1 Capitolo 13 File System Problema 1: Le copie di un file possono essere inconsistenti, quindi per sbaglio si potrebbero leggere dati vecchi. È meglio creare un link a data nella home di ogni utente. Tuttavia, è più probabile che un utente cancelli un file non più necessario piuttosto che un link a un file non più utilizzato. Quindi, si potrebbero avere link pendenti nel momento in cui il proprietario didata decide di cancellare il file. Problema 2: Assumiamo che sia richiesta esattamente una operazione su disco per accedere a un blocco dati, e che un blocco contenga esattamente o un record o l indice completo. Se i record fossero memorizzati in un file sequenziale, sarebbero necessarie, in media, 5000 operazioni su disco per accedere a un record nel file. Se i record fossero memorizzati in file sequenziale indicizzato, sarebbe necessaria una operazione su disco per leggere l indice (assumiamo che l indice sia disponibile ogni volta che si desidera accedere a un record), e una media di 50 operazioni su disco per accedere al record desiderato, quindi, in totale 51 operazioni. Problema 3: Il file sequenziale indicizzato di Figura 13.5 contiene 6 record per traccia. Assumiamo che il numero medio di record nell area di overflow di una traccia sia pari a #overflow. Da un analisi analoga a quanto fatto per il Problema 2, segue che la lettura di un record richiederebbe di eseguire una ricerca nell indice di livello più alto e nell indice della traccia, e quindi una ricerca per localizzare il record nella traccia stessa. Se l indice di livello più alto e l indice della traccia si trovano 6+#over f low ciascuno in un blocco diverso del disco, sono necessarie (2+ 2 ) operazioni su disco per accedere a un record. Quindi l efficenza di accesso a un file aumenta se il file viene ricopiato in un nuovo file che non contiene record di overflow. Problema 4: Quando a un file viene allocato spazio contiguo su disco sorgono numerosi problemi, che sono stati discussi nel Capitolo 5. Un file può superare lo spazio su disco che gli è stato assegnato. Per ridurre tale evenienza, è possibile allocare al file un area molto grande. Tuttavia, tale approccio porta a frammentazione interna senza eliminare il problema del tutto. I sistemi operativi più vecchi (per esempio

2 File System 57 OS/360) allocavano spazio per un file su più aree contigue chiamate extent. L approccio di Amoeba evita il verificarsi della frammentazione interna. Il suo principale svantaggio però consiste nel costo aggiuntivo in termini di tempo di CPU e tempo di I/O. Problema 5: Si. L allocazione concatenata interferisce con le tipologie di organizzazione dei file sequenziale e diretta. L allocazione indicizzata introduce un elemento di indirezione; tuttavia non induce un costo aggiuntivo rilevante. Problema 6: (a) La FMT contiene puntatori a 12 record. Ogni record può essere letto in 3 msec, e richiede 5 msec di tempo di elaborazione da parte della CPU. I record devono essere acceduti leggendo prima un blocco indice per ottenere il relativo indirizzo. Quindi l accesso a ciascuno dei record richiede (3+3) msec, e la sua elaborazione richiede 5 msec. Di conseguenza, il tempo totale trascorso è = (3+5) 12+(3+3+5) 4988 msec = secondi. (b) 12 record vengono acceduti direttamente. Ogni blocco indice contiene 1024 record, e quindi 1024 record possono essere acceduti usando un blocco indice che si trova in memoria. Ciò viene fatto 4 volte. 892 blocchi vengono acceduti usando il quinto blocco indice. Quindi il tempo totale trascorso è = (3 + 5) 12+4 (3+(3+5) 1024)+(3+(3+5) 892) = secondi. Problema 7: Per trovare il minimo numero di operazioni necessarie per riflettere il cambiamento sul disco, si consideri l aggiunta di un record alla fine del file. Per memorizzare il record può essere allocato un nuovo blocco su disco, e quest ultimo può essere aggiunto alla FMT del file. Assumendo che l ultimo blocco della FMT contenga spazio sufficiente per accogliere la nuova entry, è necessario riscrivere su disco solo il blocco del disco che contiene il nuovo record e un blocco della FMT. Quindi il minimo numero di operazioni su disco è pari a 2. Se il sistema operativo utilizza una cache per il disco, le precedenti operazioni non devono essere eseguite istantaneamente. Per trovare, invece, il massimo numero di operazioni necessarie, si consideri che un blocco del disco contiene molti record di un file e si supponga che il nuovo record venga aggiunto nel primo blocco. Di conseguenza, uno dei blocchi si espanderà sul prossimo blocco, e così via, in modo che tutti i blocchi relativi al file vengono aggiornati. L ultimo record del file può espandersi su un nuovo blocco, che deve quindi essere scritto. In base all organizzazione della FMT, alcuni blocchi della FMT stessa devono essere riscritti. Se viene utilizzata la modalità full journaling, tali blocchi vengono scritti immediatamente sul disco; altrimenti la scrittura di alcuni di essi può essere ritardata fino al momento della chiusura del file. Problema 8: Si consideri l inserimento di alcuni byte in un file. Il blocco su disco contenente i nuovi dati, così come tutti i blocchi che contengono i dati successivi,

3 58 Manuale delle soluzioni: Sistemi Operativi - Dhamdhere devono essere aggiornati. Tuttavia, quando un file può avere blocchi parzialmente pieni, solo un blocco su disco deve essere modificato qualunque dato che si estenda oltre può semplicemente essere riscritto in un nuovo blocco da aggiungere al file. Problema 9: Per accedere a un blocco su disco non danneggiato (good block), è richiesta un operazione su disco. Tre operazioni su disco sono invece richieste per un blocco danneggiato (bad block): una per leggere il bad block, una per leggere la tabella dei bad block e una per leggere il blocco su disco alternativo. Il numero medio di blocchi necessari per leggere un record è = operazioni = 1.04 operazioni. Pertanto i bad block degradano del 4% le prestazioni del disco. Per minimizzare il degrado delle prestazioni, la tabella dei bad block può essere tenuta completamente in memoria. Ciò ridurrebbe il degrado al 2%. Per eliminare completamente il degrado dovuto ai bad block, il file system può prima consultare la tabella per verificare se il blocco da accedere è un bad block e di conseguenza accedere o al blocco stesso o al corrispondente blocco alternativo. Problema 10: Non è sufficiente eseguire un unico controllo di validità all apertura del file; è necessario effettuare un controllo ad ogni operazione su file per garantire che l operazione sia consistente con il modello di elaborazione del file indicato nell istruzione open. Il modo migliore per implementare tale strategia consiste nell aggiungere un nuovo campo al FCB per memorizzare la modalità di elaborazione riferita nell istruzione open e controllare la relativa consistenza con ogni operazione su file. Problema 11: (a) No se viene indicato il path relativo. Gli FCB dovrebbero essere creati per tutte le cartelle del path, falla radice alla cartella corrente. (b) No. (c) È possibile aggiungere un nuovo campo a ogni cartella contenente l indirizzo della cartella padre. Se la dimensione di una cartella aumenta, il file system può usare il puntatore per accedere alla cartella padre e aggiornare al suo interno la entry della cartella figlio. Questo campo serve anche quando si usa un path relativo per accedere a un file. Problema 12: (a) Il mount a cascata descritto nella domanda è realizzabile. La sua implementazione richiede solo piccole modifiche all algoritmo usato dal file system per (1) aggiornare la directory e (2) allocare spazio su disco per il file nel file system in cui risiede. Il mount a cascata è semplice da realizzare in un sistema operativo tradizionale, ovvero non distribuito; al contrario diventa complesso in un sistema distribuito. La Sezione tratta il mount nel Network File System (NFS) di SUN.

4 File System 59 (b) Il mount multiplo è semplice da implementare, ma da origine a una serie di problemi semantici. Per esempio, un file X che si trova in un file system montato più volte può essere aperto usando due pathname diversi. I file associati a tali pathname devono essere trattati come copie dello stesso file o come file differenti? La semantica deve essere specificata chiaramente. (Si veda la Sezione in merito alla condivisione dei file). Problema 14: Se il guasto si verificasse dopo il passo 3, il blocco d 1 non sarebbe aggiornato. Pertanto, i dati puntati da d 1 non andrebbero persi. Tuttavia, si potrebbe avere inconsistenza nei dati di due file come descritto nella Sezione Problema 15: La tabella di allocazione dei file di Unix (si veda la Figura 13.33) dovrebbe essere utilizzata in modo opportuno. Problema 16: (a) Gli FCB dei file stdin e stdout sono creati quando viene creato il processo e sono assegnati per default al terminale dell utente. Quando l utente ridireziona tali file in un comando usando gli operatori < e >, il contenuto degli FCB di stdin e stdout vengono cambiati per puntare ai file menzionati nel comando, e il vecchio contenuto degli FCB viene salvato. Quindi, i file riferiti nel comando vengono aperti. Quando l esecuzione del comando termina, la shell di Unix chiude i file usati nel comando e ripristina il vecchio contenuto degli FCB in modo che i comandi successivi possano usare stdin e stdout. (b) In seguito a un comando >>, il contenuto dello FCB viene modificato come per il punto (a). Inoltre, il campo contenente l indirizzo del prossimo record da elaborare viene impostato in modo da farlo puntare al record successivo all ultimo record del file. Problema 17: Si ricordi la struttura della free list del file system Unix che è stata descritta nella Sezione Quando un file viene cancellato, tutti i blocchi su disco i cui indirizzi appaiono nella tabella di allocazione del file, chiamata FMT nella vista concettuale, dovrebbero essere inseriti nella free list. Ogni blocco della free list di Unix è un blocco indice, che usa un unico livello di indirezione. Quindi, i blocchi con indirezione doppia e tripla dovrebbero essere organizzati su liste di blocchi con indirezione singola quando vengono inseriti nella free list. Problema 18: L affermazione è sostanzialmente vera. In un sistema operativo convenzionale, i processi utente richiedono servizi del kernel tramite chiamate di sistema, e il kernel manda in esecuzione il corrispondente gestore degli eventi essenzialmente, alcuni processi kernel eseguono le funzioni richieste. In Unix, quando un processo utente esegue una chiamata di sistema, il processo stesso esegue il codice per la gestione dell evento. Quindi, parecchi processi potrebbero essere eseguire

5 60 Manuale delle soluzioni: Sistemi Operativi - Dhamdhere codice del kernel. Unix impedisce che vi siano interferenze tra questi processi usando lock sulle strutture dati critiche. Un processo che sta per usare una struttura dati attende finché può acquisire il lock corrispondente. Quindi, quando termina l uso della struttura dati, il processo libera il lock. Le strutture dati non hanno bisogno di essere bloccate in un sistema operativo convenzionale se si garantisce che il processo di sistema che gestisce l evento termini la sua elaborazione senza essere interrotto. Ciò può essere ottenuto disabilitando gli interrupt quando un processo kernel è in esecuzione; tuttavia, in tal modo il kernel non può rispondere immediatamente ad eventuali interrupt con priorità elevata. Un meccanismo alternativo è il seguente: quando arriva un evento, il gestore verifica se sia in fase di elaborazione evento simile. In tal caso, il nuovo evento viene messo in una coda di richieste e deferito rispetto all evento che è in fase di elaborazione. La coda delle richieste viene gestita dopo il completamento della elaborazione dell evento corrente.