Sistema Operativo Architettura degli elaboratori 1 - A. Memo 373 6.3 La gestione dei processi stallo 9 soluzione corretta si utilizzano un semaforo per.

Presentazione sul tema: "Sistema Operativo Architettura degli elaboratori 1 - A. Memo 373 6.3 La gestione dei processi stallo 9 soluzione corretta si utilizzano un semaforo per."— Transcript della presentazione:

1 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 373 6.3 La gestione dei processi stallo 9 soluzione corretta si utilizzano un semaforo per ogni forchetta (f[1..5]) per evitare che venga utilizzata da più filosofi, ed un semaforo per la mutua esclusione (mutex) al momento del prelievo delle forchette void filosofo_i_esimo(){ while (1) { // medita wait(mutex); wait(f[i]); wait(f[(i+1)%5]); signal(mutex); // mangia signal(f[i]); signal(f[(i+1)%5]); }

2 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 374 6.4 La gestione della memoria generalità l nei SO multitasking dobbiamo far coesistere più processi nella memoria principale l il SO deve gestire la memoria –virtualizzando la dimensione della memoria fisica ed adeguandola allo spazio logico di più processi –caricando i programmi in memoria (loader) –assegnando e recuperando la memoria ai vari processi (allocation e de-allocation) –rimpiazzando gli spazi opportuni in base alle richieste (replacement) –realizzando opportuni schemi di protezione

3 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 375 6.4 La gestione della memoria manipolazione degli indirizzi... ; char x = 0;... ; file sorgente xxxx3A COMPILER 12B5 LINKER identificatore indirizzo rilocabile indirizzo assoluto rilocabile C3B5 LOADER indirizzo logico 890E indirizzo fisico CPU/MMU file obj file exe variabile swap C:8 P:1 S:2 S.O. indirizzo memoria secondaria

4 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 376 6.4 La gestione della memoria loader 1 l caricamento dinamico –al fine di minimizzare loccupazione di memoria, si carica solo la parte necessaria del programma, e poi si attivano swap opportuni l linking dinamico –caricamento dinamico delle librerie alla loro occorrenza (Dynamic Link Libraries o Shared Object)

5 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 377 6.4 La gestione della memoria loader 2 l overlay –divisione del programma tra moduli che devono risiedere sempre in memoria e moduli autonomi che svolgono funzioni specifiche –caricamento stabile dei moduli fissi e caricamento alternato dei moduli specifici –adottato nei SO che non adottano il principio della memoria virtuale, la gestione è a carico dellapplicazione

6 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 378 6.4 La gestione della memoria allocazione della memoria 1 l a singola partizione –la memoria è condivisa tra lunico programma utente ed il SO –per evitare conflitti si utilizzano due registri: base, utilizzato anche per la rilocazione, che punta allinizio dellarea di memoria del proceso utente, e limite, che contiene la dimensione massima dello spazio utente

7 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 379 6.4 La gestione della memoria allocazione della memoria 2 S.O. utente CPU IL<limite ? base limite + Indirizzo Logico Indirizzo Fisico NO SI indirizzo illegale

8 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 380 6.4 La gestione della memoria allocazione della memoria 3 l a partizioni multiple –la memoria è condivisa da più programmi utente e dal SO –ad ogni processo viene assegnata una partizione fissa, di dimensione prestabilita (molto poco efficiente) o in base alle esigenze del processo –si inducono problemi analoghi a quelli della paginazione (tecniche di allocazione e fram- mentazione interna) (compattazione)

9 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 381 6.4 La gestione della memoria allocazione della memoria 4 l paginazione –tecnica già affrontata nellanalisi delle CPU perché la tendenza è di gestirne il meccanismo sempre più con modalità hardware (più veloci) –si divide la memoria in blocchi di dimensioni uguali (frame in memoria fisica, page in memoria logica) –ai processi vengono assegnate le pagine necessarie, anche non consecutive

10 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 382 6.4 La gestione della memoria allocazione della memoria 5 l paginazione (segue) –lindirizzo si scompone in due campi, e la traduzione da PageL a PageF avviene mediante una page table, normalmente implementata tramite TLB –nella page table si possono aggiungere anche bit per la protezione –la paginazione permette anche la condivisione in sola lettura (programmi condivisi e dati distinti)

11 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 383 6.4 La gestione della memoria allocazione della memoria 6 l segmentazione –la memoria è vista come un insieme di segmenti di diverse dimensioni –un indirizzo è composto dallindirizzo di inizio del segmento (o da un indice che lo identifica) e dalloffset del dato dentro al segmento –la traduzione da indirizzo logico (segmento più offset) in indirizzo fisico avviene mediante tabelle, normalmente complete di bit di protezione –si induce frammentazione esterna

12 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 384 6.4 La gestione della memoria memoria virtuale 1 l già trattata nellanalisi delle CPU –consente di eseguire programmi più grandi della memoria fisica a disposizione –consente di caricare in memoria solo le parti più utilizzate del programma –è più facile da programmare rispetto agli overlay o tecniche analoghe perché indipendente dal sistema –aumenta il tasso di multitasking della CPU

13 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 385 6.4 La gestione della memoria memoria virtuale 2 l può essere implementata sia tramite demand paging che con demand segmentation l demand paging –un processo è costituito da un insieme di pagine poste in memoria secondaria e solo quella necessaria è presente anche in memoria principale –si può anche tentare di prevedere quali saranno le prossime pagine ed anticiparne il caricamento

14 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 386 6.4 La gestione della memoria memoria virtuale 3 l demand paging (sequenza operativa) –dato lindirizzo logico, mediante funzione di traduzione si perviene allindirizzo fisico –si controlla il bit di validità nella tabella: l se bit=1 vuol dire che la pagina è in memoria principale, e quindi si procede al recupero del dato l se bit=0 la pagina è su disco, e si produce page fault –si controlla se loperazione richiesta è consentita l in caso contrario viene ancora prodotto un page fault

15 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 387 6.4 La gestione della memoria memoria virtuale 4 l demand paging (page fault) –se è dovuto ad accesso illegale, il processo viene fatto terminare e le sue pagine rilasciate –altrimenti si cerca un frame libero l se cè lo si alloca l se non cè, si rimpiazza uno già utilizzato (replacement) eventualòmente salvando le pagine modificate (dirty bit) –si aggiorna la page table in base al nuovo stato –si riparte dallistruzione che ha causato il page fault

16 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 388 6.4 La gestione della memoria memoria virtuale 5 l demand paging (politiche di rimpiazzo 1) –FIFO, First In First Out, implementata con una lista degli ingressi o con lorario di arrivo (?), facile ma poco efficiente –LRU, Least Recently Used, si sostituisce la pagina che è rimastata inutilizzata da più tempo, richiede lorario dellultimo impiego (?); si adottano tecniche più semplici quali il contatore di accessi alla pagina (LFU) o tramite stack

17 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 389 6.4 La gestione della memoria memoria virtuale 6 l demand paging (politiche di rimpiazzo 2) –LRU a bit di accesso, ad ogni accesso si setta il bit relativo alla pagina, e periodicamente si azzerano tutti i bit, semplice ma inefficace –LRU a bit multipli di accesso, invece di azzerarli, i bit di accesso vengono memorizzati in un byte shiftando il contenuto preesistente (rappresenta una storia della pagina negli ultimi 8 cicli di clock)

18 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 390 6.4 La gestione della memoria memoria virtuale 7 l demand paging (assegnazione dei frame) –allavvio di un processo vanno attribuiti allo stesso un certo numero di frame –il numero di frame posseduti influenza la probabilità di page fault –vengono attribuiti in base alla priorità del processo ed alla sua dimensione –il rimpiazzo di una pagina è bene venga limitato ai frame posseduti da quel processo

19 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 391 6.4 La gestione della memoria memoria virtuale 8 l demand paging (working-set model) –se le pagine richieste in una certa attività sono note a priori (working-set). possono essere caricate preventivamente, al fine di eliminare o minimizzare i page fault –è il SO che memorizza i working-set delle applicazioni in uso e li riutilizza alla prossima esecuzione

20 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 392 6.5 La gestione dellI/O generalità 1 l la gestione dellI/O è la parte più monotona, meno impegnativa e più consistente dei SO l i dispositivi di I/O sono molto diversi tra di loro come modalità duso e prestazioni: dischi (a livello logico, come estensione della me- moria principale, sono anche una risorsa) terminali video (testuali o grafici) dispositivi dingresso (tastiera, mouse, bar reader) stampanti nastri magnetici schede di rete

21 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 393 6.5 La gestione dellI/O generalità 2 l lobiettivo dei moderni SO è di gestire con le medesime modalità, ove possibile, tutti i dispositivi di I/O l lorganizzazione generale prevede almeno tre componenti: –il gestore della risorsa –il controllore della risorsa –la risorsa

22 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 394 6.5 La gestione dellI/O generalità 3 risorsa processi utente richiesta utilizzo verifica accesso Gestore della risorsa azioni elementari device driver controllore della risorsa risultato utilizzo accesso negato

23 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 395 6.5 La gestione dellI/O gestore della risorsa l i compiti del gestore della risorsa sono: –verificare se il processo richiedente ha i diritti necessari per effettuare loperazione richiesta –accodare la richiesta nella coda delle richieste e predisporre gli eventuali ed opportuni buffer –scomporre le richieste pervenute nelle singole attività necessarie, passando dalla visione astratta e generalizzata della risorsa a quella reale –utilizzare il driver della risorsa per accedervi –intercettare e gestire le interruzioni della risorsa

24 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 396 6.5 La gestione dellI/O controllore della risorsa l il controllore della risorsa, il più delle volte implementato con dispositivi hardware programmabili, deve –pilotare direttamente linterfaccia della risorsa, accedendovi a livello fisico –è quasi sempre dipendente dal particolare tipo di dispositivo di I/O gestito e qundi totalmente privo di standard

25 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 397 6.5 La gestione dellI/O esempio: lo spooling l la stampante è una delle periferiche di uscita più lente e con tempi di risposta altamente variabili l fa normalmente uso di un buffer di stampa, ma inevitabilmente presenta un comporta- mento a burst l Simultaneous Peripherical Operation On Line (SPOOL) sostituisce il buffer con un file in memoria secondaria

26 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 398 6.5 La gestione dellI/O esempio: il disco magnetico l ammettendo una coda di richieste, è utile schedularle secondo politiche appropriate: l FCFS, First Come First Served, esegue le richieste così come sono arrivate l SSTF, Shortest Seek Time First, si esegue prima la richiesta più vicina l SCAN, si eseguono le richieste più vicine, mantenendo la direzione di scansione

27 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 399 6.5 La gestione dellI/O disco: politica FCFS 0510152025303540 T FCFS = 4 + 2 + 22 + 32 + 15 = 75 molto semplice ma poco efficiente

28 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 400 6.5 La gestione dellI/O disco: politica SSTF 0510152025303540 T SSTF = 2 + 2 + 7 + 15 + 32 = 58 efficiente, ma usura maggiormente i cilindri centrali

29 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 401 6.5 La gestione dellI/O disco: politica SCAN 0510152025303540 T SCAN = 3 + 17 + 22 + 2 + 8 = 52 efficiente e con trattamento paritetico

30 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 402 6.6 File system e protezione generalità l Il File System (FS) garantisce laccesso e lorganizzazione della memoria secondaria l il FS permette di vedere più dischi fisici come lo stesso volume logico oppure più volumi logici sullo tsesso disco fisico l la sua gestione si integra facilmente con quella della protezione e della sicurezza

31 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 403 6.6 File system e protezione file l un file è uninsieme di informazioni caratterizzate da un nome comune e memo-rizzate in memoria secondaria l è una struttura logica mappata in un dispositivo fisico l il formato viene scelto alla sua creazione l le caratteristiche dei file sono: attributistruttura operazioni ammesse

32 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 404 6.6 File system e protezione attributi 1 l gli attributi che caratterizzano un file sono –nome (da 8 a 256 caratteri, case sensitive o no) –estensione o tipo (eseguibile, oggetto, sorgente) –dimensione –istanti di creazione e modifica –parentela (processo padre ed eventuali figli) –schemi di protezione (lettura, scrittura, modifica)

33 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 405 6.6 File system e protezione attributi 2 ProtezioneChi e come può accedere ad un file PasswordCodice necessario per accedere al file CreatorID dellutente che ha creato il file Ownerutilizzatore corrente del file Read-only flag0 - lettura/scrittura1 - sola lettura Hidden flag0 - normale1 - non visibile System flag0 - normal e1 - file di sistema Archive flag0 - salvato (back up)1 - non salvato ASCII/binary flag0 - ASCII1 - binario Random access flag 0 - sequenziale1 - casuale Temporary flag0 - normale1 - eliminare al termine Lock flags0 -liberon - bloccato Record lengthNumero di byte in un record

34 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 406 6.6 File system e protezione struttura 1 l Un file ha una struttura fisica composta da blocchi di dati (cluster), mentre a livello logico è visto come uninsieme di byte o di record. Il SO le mette in relazione. l le possibili strutture logiche di un FS sono: –a flusso di byte –a record di lunghezza fissa –a record di lunghezza variabile

35 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 407 6.6 File system e protezione struttura 2 l a flusso di byte (byte stream) –il SO non sa come interpretare il contenuto del file, lo sa solo lutente –il SO utilizza un puntatore relativo allinizio del file per accedere ai dati cercati –massima flessibilità per il SO

36 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 408 6.6 File system e protezione struttura 3 l a record di lunghezza variabile –delimitati da indicatori di fine record –ogni record è contraddistinto univocamente da una chiave –tutte le chiavi sono raccolte in una tabella a parte, ordinata secondo la chiave, contenente anche i puntatori allinizio del record nel file

37 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 409 6.6 File system e protezione struttura 4 l a record di lunghezza fissa –gli spazi vuoti sono riempiti da caratteri NULL o SPACE –il SO conosce la struttura del file –puntatore al record corrente –meno utilizzati dei precedenti

38 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 410 6.6 File system e protezione operazioni ammesse 1 l altre operazioni più complesse si ottengono con opportune combinazioni delle precedenti l creare un file l scrivere un file l leggere un file l rinominare un file l posizionamento interno l eliminare un file l troncare un file l spostare un file

39 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 411 6.6 File system e protezione operazioni ammesse 2 l apertura file –per accedere ad un file, bisogna prima aprirlo, cioè far si che il SO predisponga unopportuno strumento di accesso a quel file (handle) –al termine delluso di un file, questo dovrà essere chiuso –il SO multiutente UNIX ha una tabella dei file aperti a due livelli, nel primo ci sono le informazioni del file comuni a tutti i processi, nel secondo i dati specifici del particolare processo

40 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 412 6.6 File system e protezione metodi di accesso ai file 1 l accesso sequenziale –viene gestito un record (o un byte) alla volta –il SO utilizza un puntatore al record/byte corrente, e ad ogni lettura lo fa avanzare –il file può essere letto solo in ordine crescente, una rilettura richiede la ripartenza dallinizio –ad ogni scrittura il record/byte viene aggiunto in coda e si aggiorna il puntatore

41 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 413 6.6 File system e protezione metodi di accesso ai file 2 l accesso diretto –si può leggere un record/byte posto in posizione qualsiasi –la posizione del record nel file è calcolata rispetto al suo inizio (offset = 0) l accesso indicizzato (ISAM) –un file di chiavi ordinate contenente gli offset dei rispettivi record nel file, posto in RAM –ricerca binaria sul file chiavi e poi accesso diretto

42 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 414 6.6 File system e protezione esempio duso di un file in C #include #define BUF_SIZE 4096 #define MODE 0666 void main(int argc, char *argv[]){ FILE *fp; char dato; if (argc != 2) { printf( Manca il nome del file.); exit (1); } if ((fp=fopen(argv[1],w))==NULL){ printf(Impossibile aprire file); exit(1); } do { dato = getchar(); if (EOF == putc (dato, fp)) { printf(Errore nel file.\n); break; } } while (dato!=ESCAPE); fclose(fp); }

43 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 415 6.6 File system e protezione file mappati in memoria l il SO può mappare in memoria virtuale un file, cioè attribuire a quel file una data area di memoria (meglio un segmento perché preserva loffset) e poi gestirne gli accessi come se fossero indirizzi di memoria l quando il file viene chiuso tutte le modifiche apportate nellarea di memoria vengono riportate sul file

44 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 416 6.6 File system e protezione struttura della directory 1 l Ogni volume logico contiene uno o più file ed una o più directory di file l le directory possono essere classificate in –directory a livello singolo –directory a due livelli –directory ad albero –directory a grafo aperto –directory a grafo generalizzato

45 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 417 6.6 File system e protezione struttura della directory 2 l directory a livello singolo –tutti i file sono organizzati in ununica grande lista, ognuno con un nome diverso –semplice da capire ed implementare, ma difficile da gestire per il gran numero di file NomeFileattributipuntatoredati FILE 1FILE 2FILE 3FILE 4FILE 5FILE 6

46 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 418 6.6 File system e protezione struttura della directory 3 l directory a due livelli –una Master File Directory contenente tante User File Directory quanti sono gli utenti –quando un utente entra (log-in) vede solo la sua UFD –utile nei SO multiuser perché isola gli utenti –il SO per accedere ai file usa il path name –i programmi di sistema possono o essere copiati su tutte le UFD (pessimo), o si introduce il concetto di search path e directory di sistema

47 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 419 6.6 File system e protezione struttura della directory 4 l directory ad albero –numero arbitrario di livelli –il livello superiore viene detto root level –ogni directory può contenere file o sottodirectory –ogni utente ha la sua directory corrente, che può essere cambiata con comandi di sistema –se non si specifica il path name, è quello corrente –il path name può essere assoluto o relativo

48 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 420 6.6 File system e protezione struttura della directory 5 / radice studenti docenti RossiBianchi doc prg A2A1 misc odb D1D2 Esempi: directory corrente: Rossi directory padre:. directory figlio:.. il file A1 può essere chiamato doc/A1 (relativo) /studenti/Rossi/doc/A1 il file D1 di un altro ramo (purchè abilitato):../studenti/Bianchi/odb/D1 (relativo) /studenti/Bianchi/odb/D1 (assoluto)

49 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 421 6.6 File system e protezione struttura della directory 6 l directory a grafo aperto –rappresenta la generalizzazione dellalbero, in cui un file può essere condiviso da più directory –in UNIX si utilizzano dei collegamenti simbolici tra nome locale e quello reale; il SO potrà avere collegamenti ciclici (riferimenti circolari) studenti RossiBianchi prg –in altri SO si duplicano gli identificatori (handle) dei file: coerenza difficile da assicurare

50 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 422 6.6 File system e protezione operazioni con le directory l create dir crea una nuova sottodirectory l delete dir elimina una sottodirectory l change dir cambia la directory corrente l rename dir cambia nome alla sottodirectory l link /unlink crea/annulla collegamenti simbolici

51 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 423 6.6 File system e protezione implementazione del file system 1 l i dischi vengono letti e scritti a blocchi (cluster) l ogni blocco è composto da uno o più settori l caricamento del File System (mounting) –il SO inserisce il dispositivo specificato nel punto indicato della directory corrente –in UNIX può avvenire in run time

52 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 424 6.6 File system e protezione implementazione del file system 2 File System logico organizzazione dei file File System fisico Device driver Disk driver e controller tabella dei file aperti dai comandi di alto livello (API del SO) a quelli di basso livello (hardware) dalle informazioni simboliche allallocazione logica dai blocchi logici di un file a quelli fisici lettura/scrittura dei blocchi fisici hardware controllabile e programmabile mappa allocazione buffer daccesso parametri config.

53 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 425 6.6 File system e protezione implementazione dei file 1 l allocazione contigua –memorizzazione dei file in blocchi fisici consecutivi –un file è identificato dallindirizzo del primo blocco e dal numero di blocchi utilizzati –supporta laccesso sequenziale e diretto, ha ottime prestazioni (una sola operazione di I/O) –induce frammentazione interna ed esterna (eliminabile con la compattazione), richiede la conoscenza anticipata della dimensione massima

54 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 426 6.6 File system e protezione implementazione dei file 2 l allocazione a lista concatenata –un file è rappresentato da una lista concatenata di blocchi fisici –nella directory il file è caratterizzato dal puntatore al primo blocco ed in alcuni SO anche allultimo –i blocchi dei file contengono il puntatore al blocco successivo (o NULL) e poi i dati –la lettura sequenziale è semplice, quella diretta più complessa –si induce frammentazione interna e laffidabilità della lista rappresenta un problema

55 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 427 6.6 File system e protezione implementazione dei file 3 l File Allocation Table (MS DOS e successivi) l tabella ordinata di puntatori, uno per ogni blocco del disco 0blocco libero Nblocco successivo del file EOF ultimo blocco del file l tutta o parte della FAT deve essere copiata in RAM l permete laccesso diretto 0 0 0 1 4 2 0 3 5 4 6 5 EOF 6 0 7 FILE_1 2 vuoti 4 5 6 FAT

56 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 428 6.6 File system e protezione implementazione dei file 4 l allocazione a lista indicizzata –una lista di puntatori ai blocchi affianca la directory –quando si crea un file si aggiunge il descrittore relativo nella directory e si crea un blocco indice, con tutti i puntatori a NULL –tutti gli accessi contemplano unoperazione di ricerca su blocco indice e poi un accesso diretto al blocco contenente i dati cercati

57 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 429 6.6 File system e protezione implementazione dei file 5 l allocazione a lista indicizzata (segue) –non cè frammentazione esterna, non è richiesta la dimensione massima, implementa accessi sequenziali e diretti –per file molto piccoli un blocco indice è sprecato –per file molto grandi si possono concatenare più blocchi indice, o organizzarli a più livelli gerarchici

58 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 430 6.6 File system e protezione implementazione dei file 6 l allocazione a nodi indice (i-node) –ad ogni file viene associata una tabellina contenuta in un blocco, detta i-node, che contiene gli attributi del file ed i puntatori ai blocchi del file relativo –file piccoli: gli indirizzi dei blocchi contenenti i dati sono memorizzati direttamente in un numero contenuto di campi delli-node –file medi: oltre agli indirizzi precedenti, cè un campo che punta ad un single indirect node posto in un blocco

59 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 431 6.6 File system e protezione implementazione dei file 7 % segue –file grandi: oltre a quanto visto, un campo punta a un livello di blocchi intermedio che a loro volta puntano ai blocchi diretti dei dati –file molto grandi; si può arrivare a tre livello di reindirizzamento –la struttura di i-node deve essere salvata inizialmente in memoria, per una più rapida consultazione –viene utilizzata in UNIX

60 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 432 6.6 File system e protezione implementazione dei file 8 l gestione dei blocchi vuoti –vettore di bit, ogni bit indica lo stato del blocco relativo, 0 = libero, 1 = occupato –lista concatenata, sfruttando i campi puntatore al successivo

61 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 433 6.6 File system e protezione implementazione delle directory 1 l la funzione delle directory è quella di suddividere lo spazio fisico della memoria secondaria in più aree logiche distinte, e lobiettivo della loro implementazione è quello di correlare la stringa ASCII del nome del file alle informazioni necessarie al recupero di quel file l le directory possono essere implementate con –liste lineari ad uno o più livelli –ricorrendo a tabelle di hash

62 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 434 6.6 File system e protezione implementazione delle directory 2 l lista lineare –ogni elemento della directory rappresenta un file (o una sottodirectory) caratterizzato dal suo nome e dai relativi attributi –non cè un ordine specifico, ed i tempi di ricerca sono elevati l tabella di hash –cè ancora una lista lineare, ma mediante una tabella dei nomi e dei puntatori ai relativi elementi della lista, laccesso è velocizzato

63 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 435 6.6 File system e protezione implementazione delle directory 3 Directory gerarchica a più livelli. campi della directory a 32 bit: 1 Nome file:8 bytes 5 Orario:2 bytes 2 Estensione file3 bytes 6 Data:2 bytes 3 Attributi:1 byte 7 Primo blocco:2 bytes 4 riservati:10 bytes 8 Dimensione:4 bytes Orario (unsigned a 16 bit):Data (unsigned a 16 bit): 2048*Ore[2048*24=41.184]512*(anno-1980) = 1980-2108 32*minuti [32*60=1920]32*mese[32*12=384] 0,5*secondi[60/2=30]1*giorno[31] 1 2 3 4 5 6 7 8 Riservato per sviluppi futuri MS-DOS

64 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 436 6.6 File system e protezione UNIX - file system 1 Il file system di UNIX è composto da 4 elementi: l boot block (blocco 0) –non sempre usato, contiene il programma di boot l superblock (blocco 1) –informazioni sulla struttura del file system (numero di i-node, numero di blocchi sul disco, inizio della free list, flag di modifica e di bloccaggio...)

65 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 437 6.6 File system e protezione UNIX - file system 2 l lista degli i-node (a partire dal blocco 2) –contiene un i-node per ogni file –ogni i-node occupa 64 Byte e la lista ne può contenere 65.535 –un i-node contiene informazioni sul file relativo (processo utilizzatore, protezioni, orario dellultimo accesso e modifica, dimensione, indirizzi per localizzare i blocchi contenenti i dati del file,...)

66 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 438 6.6 File system e protezione UNIX - file system 3 l blocchi di dati, contenenti –la directory radice –tutte le sottodirectory e la loro organizzazione –la lista dei blocchi liberi su disco –i blocchi di primo, secondo e terzo livello di reindirizzamento dei vari file presenti –un file può occupare anche blocchi non contigui

67 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 439 6.6 File system e protezione UNIX - elemento di directory l un elemento di directory è composto da: –numero delli-node relativo al file (2 byte) –nome del file (stringa ASCII da 14 byte max) l una directory viene memorizzata in un blocco del disco, e contiene i nomi dei suoi file ed i puntatori ai relativi i-node l in un blocco da 1Kbyte si possono inserire 64 elementi di directory (da 16 byte ciascuno)

68 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 440 6.6 File system e protezione affidabilità del file system 1 l gestione dei blocchi danneggiati –hardware, creando in un settore del disco un elenco di blocchi danneggiati ed i loro sostituti –software, ricorrendo ad un falso file che utilizza tutti i blocchi danneggiati l salvataggio del file system –su nastro, tempi lunghi, possibilità incrementale –su disco, con partizione di backup o RAID, Redundant Array of Inexpensive Disks

69 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 441 6.6 File system e protezione affidabilità del file system 2 l consistenza del file system –un file viene aperto, modificato e poi salvato; se il sistema cade tra la modifica ed il salvataggio, il file risulta essere inconsistente –consistenza dei blocchi: si producono due liste, un contatore per ogni blocco; la lista dei blocchi in uso dei file e la lista dei blocchi liberi. l consistenza: ciascun blocco appartiene ad una sola lista l perdita: il blocco non appartiene ad alcuna lista l duplicazione: il contatore del blocco è maggiore di 1 in una delle due liste –consistenza dei file: analogo per i file

70 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 442 6.6 File system e protezione prestazioni del file system 1 l data la lentezza dellaccesso ai dischi, si interpone tra memoria principale e secondaria un buffer (organizzato come una cache) della dimensione di alcuni blocchi l quando il buffer è pieno si possono adottare politiche di rimpiazzo analoghe alla paginazione (LRU) l cè il problema della scrittura e della consistenza dei dati: per i blocchi i-nodes o di indirizzamento indiretto si aggiorna il disco molto frequentemente

71 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 443 6.6 File system e protezione prestazioni del file system 2 l UNIX adotta la chiamata automatica di SYNC ogni 30 secondi circa l MS-DOS adotta la politica write-through (più lenta, meno efficace, si può togliere un FD in qualsiasi momento)

72 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 444 6.6 File system e protezione sicurezza: generalità l la multiutenza e la multiprogrammazione condividono le risorse: occorre evitare utilizzi non autorizzati l protezione –meccanismi di salvaguardia delle risorse dai malfunzionamenti l sicurezza –impedire luso non autorizzato (volontario o meno) di risorse

73 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 445 6.6 File system e protezione sicurezza: intrusioni l intrusi passivi, leggono file a loro negati l intrusi attivi, apportano modifiche non consentite a file l classificabili in –intrusi di passaggio, casuali –intrusi a scopo di curiosità (interni al sistema) –intrusi a scopo di lucro –intrusi a scopo di spionaggio

74 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 446 6.6 File system e protezione sicurezza: esempio di difetto l lpr (UNIX) –il comando lpr stampa un file e, se attivata lopzione -r, il file viene successivamente rimosso: si poteva lanciare la stampa del file delle password e poi farlo eliminare, rendendo accessibile lintero sistema

75 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 447 6.6 File system e protezione sicurezza: esempi di attacchi l richiedere pagine di memoria, aree di dati o blocchi di disco: molti SO non le cancellano prima di riutilizzarle l effettuare chiamate di sistema con parametri errati o incoerenti: molti SO non prevedono tutti i casi possibili l digitare DEL, BREAK o simili allinterno della password: il SO potrebbe chiudere il programma di test e considerare valido il login

76 Sistema Operativo Architettura degli elaboratori 1 - A. Memo 448 6.6 File system e protezione sicurezza: virus l segmento di codice aggiunto ad un programma con lobiettivo di replicarsi su altri programmi l virus di boot, attivati durante la fase di avvio si collegano alle chiamate di sistema ed infettano tutto il sistema l virus di file, presenti in fle eseguibili l virus di macro l virus polimorfi