Linus elevator vs C-SCAN

[minidiable]

Ciao a tutti vorrei sapere le differenze tra due algoritmi di scheduling per le richieste di I/O:

il C-SCAN e il linus elevator(usato da linux fino alla versione del kernel 2.4)

Io ho capito che il C-scan funziona come quello di un'ascensore circolare, quindi parte da un punto (ad esempio un estremo del disco) arriva all'altro estremo servendo tutte le richieste in ordine crescente e poi, arrivata (la testina) all'altro estremo torna al 1°estremo e ricomincia il ciclo (quindi è una versione circolare dell'algoritmo classico di Scan..)

però il linus elevator, c'è scritto sul libro che è una variante del c-scan in quanto mantiene una coda ordinata delle richieste...ma poi non dice più niente, cosa se ne fa di questa coda delle richieste?...grazie!!

[sanandreas-labs]

le smaltisce in modo leggermente più ordinato e in modo più veloce, ma le differenze sono veramente minime, C-Scan resta ancora un ottimo prodotto

[minidiable]

ehhh....ma continuo a non capire...cioè...a che gli serve la coda ordinata e quando la utilizza?...

[sanandreas-labs]

te l'ho detto, di fatto non ci sono differenze, io ti ho riportato un estratto di quello che dice la casa produttrice.

[minidiable]

Ti ringrazio...già che ci siamo...un'altra cosa..se puoi:

Il C-scan rispetto allo SCAN normale è soltanto "più equo?" cioè intendo nel senso che il C-scan ricominciando dall'inizio non comincia di nuovo da dove ha finito quindi le richieste che stanno all'inizio non devono aspettare il tempo che ci vuole per fare un altro scorrimento nel senso opposto(che avrebbero aspettato nello SCAN)?

GRAZIE

[claudiocrack]

linus elevator è ancora valido perche funziona ma è a tutti gli effetti obsoleto ed inutilizzabile.

Il problema sostanziale sta nel fratto che immagina di avere una seq di lettura

50, 60 , 86, 92, 800

Immagina che il disco sia al primo settore logico, parte l' agoritmo arriva a meta 86 e continuano ad arrivargli richieste di lavorare sul settore 86, lui continua a restare sull' 86 per questo il settore per esempio 800 restera "non servito" per molto tempo, quindi introduce problemi di latenza.

Se poi arriva una sequenza di scrittura questa avviane nei tempi della sequenza che sta magari ancora scrivendo sul settore 86 e pensa se poi il file da scrivere è abbastanza grande.

Mi sembra che appunto in questo caso si aggiungevano problemi di scritture settorializate in cui i file venivano scritti su una porzione di disco piuttosto che un altra, ma di questo la memoria non tiene conto quindi non farci caso il problema ricordo che c' è ma non ricordo per quale motivo c' è, mi sembra sia stato un compromesso per non creare altri problemi in scrittura infatti poi vennero inseriti i deadline io Scheduler e l' anticipatory io scheduler.

[minidiable]

il problema del linus elevator io so che è il cosiddetto writes starving reads...cioè gli scrittori fanno andare in starvation i lettori...forse proprio quello che hai detto tu...

per questo motivo poi si è passati al deadline scheduler nella versione di linux a kernel 2.6..

p.s. per quanto riguarda il dubbio da me espresso sul c-scan e lo scan...sei daccordo???


Grazie

[claudiocrack]

Secondo me si è cosi, pero non te o dico al 100% perche le ho viste troppo tempo fa queste cose.

[sanandreas-labs]

linus elevator è ancora valido perche funziona ma è a tutti gli effetti obsoleto ed inutilizzabile. Il problema sostanziale sta nel fratto che immagina di avere una seq di lettura 50, 60 , 86, 92, 800 Immagina che il disco sia al primo settore logico, parte l' agoritmo arriva a meta 86 e continuano ad arrivargli richieste di lavorare sul settore 86, lui continua a restare sull' 86 per questo il settore per esempio 800 restera "non servito" per molto tempo, quindi introduce problemi di latenza. Se poi arriva una sequenza di scrittura questa avviane nei tempi della sequenza che sta magari ancora scrivendo sul settore 86 e pensa se poi il file da scrivere è abbastanza grande. Mi sembra che appunto in questo caso si aggiungevano problemi di scritture settorializate in cui i file venivano scritti su una porzione di disco piuttosto che un altra, ma di questo la memoria non tiene conto quindi non farci caso il problema ricordo che c' è ma non ricordo per quale motivo c' è, mi sembra sia stato un compromesso per non creare altri problemi in scrittura infatti poi vennero inseriti i deadline io Scheduler e l' anticipatory io scheduler.

stavolta mi hai veramente stupito
e dai facciamo la pace, indubbiamente di linux ne sai più te che me