Devices OS

Devices

Categorizzazione (6)🟨-

1. Trasferimento dei dati
2. Accesso al device
3. sinfonia del trasferimento
4. condivisone fra processi
5. Velocità del trasferimento
6. I/O direction (scrittura o lettura)

Vediamo che molte caratteristiche sono riguardo il trasferimento

• Slide categorizzazione I/O

  

Blocchi o caratteri 🟩-

• Slide devices blocchi o caratteri

  

Tecniche di gestione devices (4) 🟨-

Buffering

Possiamo mettere un buffer per favorire la comunicazione fra i devices. la cosa migliore che fa è creare maggiore efficienza. Un altro motivo è la velocità diversa di consumo.

Anche le schede audio, in cui viene riempito un buffer e poi l’audio viene suonato da questo (differenza consumer e producer), anche per questo motivo è difficile sincronizzare dispositivi differenti (se hanno buffer distinti).

Cache

Invece la cache è trasparente pe ril programma, e rende il tutto più veloce. La differenza maggiore con il buffering è che qui viene mantenuta una copia, non una istanza dell’informazione.

Spooling

Gia trattato per le stampanti in Gestione delle risorse

Scheduling I/O

Storage area network 🟩

Il vantaggio principale è resilienza del server, che ho il device in altra parte. (non ho iil tight coupling fra server e disco in questo modo, prima se si rompe qualunque, si rompe il servizio).

Ora se si rompe un server, ci sarà un altro server che sostituisce, se si rompe un storage array, ci sarà ridondanza, e altro storage ti risponderebbe. Si vede che questa parte è strettamente collegata con cose fatte in Reti di Calcolatori

Memoria secondaria

Solid State Drive 🟨+

Un sacco di vantaggi come

1. Velocità di accesso
2. Meno consumo energetico
3. Meno fragilità
4. Velocità di lettura è molto veloce.
5. Poche scritture (comuqnue tante) comunque limitati cicli di scrittura.
6. Uniforme velocità in tutto il disco (questo rende l’accesso veloce :D).

Non andiamo ad approfondire sugli algoritmi di scheduling per le scritture a banco, trattiamo meglio gli HDD.

Hard Disk Drive 🟨+

Soffrono molto i terremoti perché la testina è vicina al disco e non soffrono problemi di pressione.

Devo avere:

1. Testine settore giusto
2. La traccia desiderata si muova e mi dia le cose giuste

Questo mi crea 3 parametri per valutare questo accesso

Velocità di rotazione, Tempo di seek o di cambiare cilindro**, velocità di trasferimento**.

Solitamente il tempo più lungo è per il cilindro, poi devo andare alla sezione, e andare alla testina corretta.

• In generale sul disco:

  

Ossia solitamente mezzo giro, + tempo cambio

VALUTAZIONE TEMPO DI ACCESSO

• Slide tempi di accesso per dischi

  

In media 100 giri al secondo, quindi tipo 5 ms per andare a trovare la testina corretta, potrebbe essere 2.5 se è il doppio o 1, ma l’ordine di grandezza resta questo per il ritardo.

RAID

Introduzione ai Redundant Array of Indipendent Disks

I RAID ne abbiamo parlato in Memoria. Come facciamo a stare su alla velocità del processore se questa va a crescere in modo esponenziale? Parallelizzazione della ricerca!. Ecco perché ci serve raid (oltre alla ridondanza quindi più sicuro). E possono anche fallire. → ammette recovery.

E una altra cosa bella dei raid è che sono hot-swappable cioè li puoi sostituire anche quando stanno runnando.

livello 0 (striping) 🟩

I dati vengono messi su più dischi. Viene utilizzato per applicazioni in cui serve velocità, senza interesse di perdita di dati. Ad esempio in dipartimento ci mettono copie di SO per aggiornare il sistema operativo.

UTILIZZI:

• per grandi trasferimenti di dati, efficiente, in particolare se la quantità di dati richiesta è relativamente grande rispetto alla dimensione degli strip

• per un gran numero di richieste indipendenti efficiente, in particolare se la quantità di dati richiesta è paragonabile alla dimensione degli strip

• Slide RAID 0

  

Livello 1 (mirroring) 🟩

Ci sono 2n dischi e metà sono delle copie esatte.

In questo caso la scrittura è più lenta della lettura, si può vedere però che offre una semplice e buona forma di ridondanza.

Tollera un singolo guasto al massimo, o più dischi differenti (non devono essere le due copie diciamo). Si dice fault tolerance livello 1.

Nested RAID 🟨++

We can nest raid 0 with 1 or the reverse. It has tradeoffs with respect to the I/O bandwidth. More used for large disk arrays usually present in the cloud.

Livello 2

Si usano codici di Hamming a livello bit

livello 3

Si usano bit di parità, ma lo facciamo a livello del singolo bit, mentre il livello 4 lo fa a livello del blocco.

Livello 4 🟩

La differenza col livello 3 è che questo livello è molto più Coarse-Grained (see Cloud Reliability), quindi ha una banda minore, ma latenza minore per letture larghe.

Utilizzo un intero disco solamente per la parità su un disco. così se si rompe un disco riesco a ricostruire le informazioni di quel disco.

Non è efficiente perché se cambio un dato devo andare sempre a fare due write su dischi diversi. E poi continuo sempre a scrivere sullo stesso disco! Quindi fai finta 4 write contemporanei, per aggiornare gli altri dischi! Per questo c’è il bottleneck

Livello 5 🟩

Se c’è un disco rotto si rallenta, ma non si perdono dei dati! è il funzionamento degradato dei raid. Non ho problemi di bottleneck, e ho ancora la velocità del livello 1

Livello 6 🟨++

http://www.cs.unibo.it/~renzo/doc/p245-blaum

Questo è per cose sicure, riesce a tollerare livello 2 fino a due dischi rotti. Ovviamente è una parità diversa, in modo che riesco ad avere più fault tolerance. Si utilizza un XOR in diagonale e questo sembra funzionare, anche se non ho capito perché.

• Intuizione mia In pratica qualunque modo prendi due dischi non di check (se uno è un disco di check è molto ez). Allora puoi fare questo:
  1. Recovery dei dischi in alto a sinistra e in basso a destra, questi si possono recoverare solamente con i bits diagonali, quindi posso già farlo.
  2. Utilizzo questi strips recuperati e utilizzo quelli orizzontali per recuperare l’altro della stessa row, poi utilizzo diagonale per recuperare quelli corrispondenti in row diverse e continuo così e riesco a recuperare tutto., Sarebbe molto utile fare un esempio per mostrare questo, ma spero che il me futuro quando legge questo riesca a ricordarsi l’esempio su carta.

Algoritmi per HHD

First Come First Served 🟩

Questo è un algoritmo fair, nel senso che eseguo a seconda di quanto viene, questo non general starvation. Però non minimizza il numero di seek, quindi in generale è più lento. Se invece facciamo in batch, in gruppo di richeiste alla volta sarebbe molto più semplice!

Questa è l’idea del prossimo algoritmo

Shortest Seek Time First 🟩

Seleziona la richieste che prevede il minor spostamento della testina dalla posizione corrente

può provocare starvation, quando arrivano tante vicine, non visito mai quelle lontane! (Per esempio le richieste fatte su RAID 1, scelgono il disco con meno seek time, ma questo è inteso ad un livello differente). Quindi non abbiamo fairness, e non c’è una buona velocità di risposta per le richieste agli estremi.

Look - Algoritmo dell’ascensore 🟩

Praticamente vado avanti indietro, e quando arrivo alla fine torno indietro, continuo così a soddisfare le richieste.

Il tempo medio di accesso non è omogeneo, le tracce centrali sono accesse più spesso.

• Esempio ascensore

  

DISCUSSIONE DI IMPLEMENTAZIONE

Si utilizzano due code. Una coda a scendere e una coda a salire.

Potrei creare starvation quando mi arrivano richieste sullo stesso cilindro, quindi quando succede devo mettere la richiesta nell’altra coda.

• Implementazione delle due code

  

C-Look 🟨++

È molto simile all’algoritmo dell’ascensore, ma solo che quando arrivo alla fine torno all’inizio.

Non ho ancora capito in quali casi può essere utile.

• Slide esempio C-Look