Appunti Sistemi operativi - parte 7

Gestione del disco e log filettato

Quando il disco viene riempito, per risolvere il problema viene concettualmente diviso in tanti segmenti, dove i segmenti sono dei package. La strategia più utilizzata è quella di riutilizzare lo stesso log quando tutti i segmenti sono occupati, ma questa volta il log sarà composto solo da blocchi invalidi.

Quando tutto il disco è pieno, viene gestito come tutti i blocchi invalidi e quindi i blocchi occupati non vengono più calcolati. Si procede quindi a descrivere solo quelli invalidi con il metodo del LFS. Le richieste successive considerano solo i blocchi fisici che sono stati invalidati in precedenza.

Questa tecnica prende il nome di log "filettato" perché il log è come se fosse filettato, poiché mano a mano che si fa un giro di tutto il disco si hanno dei blocchi invalidi. Quando poi il disco finisce, si procede con l'escludere.

Tutti i blocchi liberi o occupati e si procede con lo scrivere solo in quei blocchi che risultano essere invalidi. Questo comporta una grossa frammentazione del file system in quanto a mano a mano che si fanno questi giri si va sempre più spezzando la sequenzialità e quindi aumentano le scritture, aumenta la write amplification ed il disco si usura di più e va più lento. Per evitare questo tipo di problema si usa anche una Garbage Collection e si preferisce quando il disco è pieno ed ha dei blocchi invalidi compattare segmento per segmento e tenere quanto più spazio possibile contiguo sul disco. Anche con questa soluzione si utilizza il disco e quindi si usura, per cercare di usurarlo uniformemente non si fa un completamento di tutto ma si procede con delle varie tecniche segmento per segmento. Ad esempio la tecnica Greedy prende il segmento con minore numero di blocchi validi, ci sono poi altre tecniche come Cold Block o Red Block che indicano blocchi.

caldi o blocchi freddi che differenziano i blocchi a seconda di quanto questi siano statiutilizzati in passato e cercano di spostare quelli che non sono reclamati da più tempo.

A prescindere dal tipo di tecnica che si adotta possiamo osservare che in entrambe le situazioni viste avereun disco pieno comporta un aumento dell’attività che comportax Rallentamento del discox Usura più veloce

Queste problematiche causano ancora oggi un problema importante per questi SSD 858L’adozione di un Log File System è sostanzialmente agnostica rispetto al tipo di file system del SO anche seoggi piuttosto che di usare NFTS, FAT, EXT 2 si parla di montare direttamente dei log file system a livello diSO come JFFS, YAFFS che sono dei log che vanno direttamente nel SO e che hanno un livello di traduzionein meno in modo tale che al SSD arriva direttamente l’accesso ai blocchi fisici e i blocchi logici vengono adessere gestiti direttamente dal SO.

LEZIONE 31

Il Kernel possiamo definirlo come il cuore del SO che gestisce l'interfacciamento tra software e hardware; esiste quindi uno spazio astratto di esecuzione software che è codice mnemonico scritto in un linguaggio di programmazione di più o meno alto o basso livello che deve essere eseguito su un processore, l'esecuzione di questo codice non può essere fatta sempre nelle due modalità esecuzione in spazio utente e in esecuzione in modalità supervisore (Kernel mode), il Kernel funge quindi da intermediario.

Il SO non è fatto di solo Kernel ma anche di altri componenti, il Kernel è però quella parte di software che viene ad essere eseguita in modalità supervisore perché deve eseguire tutta una serie di istruzioni che vanno a modificare lo stato del sistema a livello hardware come ad esempio lo stato dei registri del processore, l'interfacciamento con l'I/O, la gestione delle chiamate di sistema ecc.

Il Kernel di Linux in particolare è basato su UNIX ma implementa interfacce simili a quelle già implementate in UNIX ma ne implementa anche altre come ad esempio abbiamo visto per gli algoritmi di scheduling a breve termine che sono implementati in Linux o ancora gli algoritmi di gestione della memoria. Linux abbiamo detto che afferisce alla classe di SO detta monolitica, di questa cosa ne abbiamo già parlato quando abbiamo introdotto i SO microkernel. La differenza sostanziale che sussiste tra un Kernel come Linux o ad esempio uno come Minix che come abbiamo visto afferisce alla categoria di microkernel e che quindi è basato su questo tipo di architettura, presenta come differenza sostanziale che tutto il codice che viene ad essere generato contiene tutto il codice del kernel e viene ad essere eseguito in un unico spazio di indirizzamento a differenza delle architetture a microkernel dove abbiamo splittato le diverse funzionalità tra user space e kernel.

Linux in particolare, a differenza di Unix, permette di caricare a runtime pezzi di codice del kernel e in questo caso l'utilizzo di questi kernel module permette di caricare il codice strettamente necessario che viene richiesto al momento.

Ad esempio, se si necessita di un driver di un dispositivo che non è presente in un dato momento nella nostra architettura hardware, si vuole evitare ovviamente di mettere tutti i possibili driver installati nel sistema operativo come ad esempio fa Windows, che mette all'installazione del sistema operativo tutti quei driver che potrebbero essere utilizzati da un utente ma potrebbe capitare che questi driver non verranno mai ad essere utilizzati.

È possibile andare a caricare anche codici di terze parti attraverso questi kernel module che non sono legati ad un driver, ma è sempre codice che deve essere eseguito nel contesto kernel, ma anche in generale librerie e codice di terze parti.

L'architettura concettuale di Linux è quella

Rappresentata sopra che più o meno è qualcosa che abbiamo già visto; in questa architettura abbiamo infatti lo strato delle applicazioni, abbiamo le librerie di sistema e poi abbiamo l’interfaccia tra il mondo user space ed il mondo kernel space, ai lati abbiamo i moduli del kernel che sono caricabili a runtime in kernel space e poi abbiamo tutta una serie di sottosistemi più o meno complessi per la gestione dei processi, abbiamo ad esempio nel modulo IPC tutta l’implementazione di quelle strutture dati che abbiamo visto per le code dei messaggi, i semafori, la shared memory ecc, abbiamo poi il gestore della memoria e lo scheduler che ha 10ine di algoritmi che possono essere adoperati. Abbiamo poi tutta la parte relativa alla gestione dei dispositivi di I/O e quindi possiamo osservare tutta quella parte più complessa dei SO ed è anche la parte più prona ad errori, infatti è stato stimato che più del 70% di un codice del

kernel che è buggato si riferisce a dei device driver è quindi importante andare a studiare come questi componenti possono fallire e qual è la genesi di questi fallimenti per poter rendere un SO più affidabile. Abbiamo poi la parte di dipendenza del codice dell'architettura hardware. L'architettura presentata sopra è un'architettura concettuale, l'architettura quasi reale è quella rappresentata in figura sotto.

Possiamo osservare come si cominciano a vedere le diverse relazioni che intercorrono tra le diverse parti. Lo sviluppatore del codice kernel di Linux si va a scontrare con un'architettura molto più complessa rispetto a quella vista prima. L'architettura quasi reale è composta da molti e diversi componenti che hanno diverse relazioni tra di loro. Il Virtual File System è un componente che consente di avere l'astrazione del concetto di file, il file come abbiamo detto nelle