Deficienza con HD moderni?

[conraid]

[..]
disattivavano la on-board memory, possibile allora,
[..]
il disco fa poi quello che vuole lui e quando vuole lui.

Ma perché allora in certi post ti vanti di avere HD con tanti mb di memory onboard? Dicendo addirittura che non parli con chi non è così all'avanguardia?
Il problema della memoria onboard serve proprio per limitare questa sensazioni di mancata "contemporaneità" di due scritture.
Per fare quello che chiedi forse serve quello che critichi sempre, le tanto bistrattate tecnologie software fatte da non geni
Per esempio un RAID 0 con più dischi potrebbe in alcune occasioni ovviare al fatto che l'hd è unico e come ti hanno detto se scrive una cosa non può "contemporaneamente" (metto tra virgolette perché dipende anche dal numero di testine e piatti) scriverne un'altra, la quale si mette in coda. Gli scheduler I/O servono proprio per gestire queste "code".
Alcuni consigliano, tramite trucchi di cui non mi sono mai interessato, di fare tante partizioni quanti sono i piatti dell'HD (facendo riferimento ai blocchi e quindi sapendo esattamente le dimensioni di ciascun piatto), in modo da migliorare le prestazioni? Altri ancora consigliano di prendere HD da terabyte ed usarne un decimo, per migliorare i "tempi morti" di riposizionamento delle testine, tipo qui
http://www.tomshw.it/storage.php?guide=20090319

Insomma, puoi migliorare le prestazioni del tuo hard-disk di un poco, ma con soluzioni che hai sempre detto inutili al giorno d'oggi.

Spero di non aver detto tante bischerate, è un settore di cui non mi sono mai occupato più di tanto

[mohaa]

what is the point of this thread, seriously ?

[Blizzard]

Per esempio un RAID 0 con più dischi potrebbe in alcune occasioni ovviare al fatto che l'hd è unico e come ti hanno detto se scrive una cosa non può "contemporaneamente" (metto tra virgolette perché dipende anche dal numero di testine e piatti) scriverne un'altra,

penso si riferisse ad un multitasking tipo processi su un solo processore (ammettiamo che ci siano 3 processi su un processore singolo task nessuno dei 3 va in stallo).
Penso che Mario cercasse la stessa cosa nel controller degli HD uno scheduler tipo time sharing che una volta scrive i dati del compressore1 e una volta scrive i dati della copia nell'ordine che viene impartito dal kernel.
Se è questa la questione suppongo che il buffering sia la soluzione comunque migliore in efficienza proprio perchè elimina i salti della testina dal file1 al file2 alla stessa frequenza con cui avviene tra il processo1 e il processo2 nel kernel.

IMVHO
Gio

[masalapianta]

Per esempio un RAID 0 con più dischi potrebbe in alcune occasioni ovviare al fatto che l'hd è unico e come ti hanno detto se scrive una cosa non può "contemporaneamente" (metto tra virgolette perché dipende anche dal numero di testine e piatti) scriverne un'altra,

penso si riferisse ad un multitasking tipo processi su un solo processore (ammettiamo che ci siano 3 processi su un processore singolo task nessuno dei 3 va in stallo).
Penso che Mario cercasse la stessa cosa nel controller degli HD uno scheduler tipo time sharing che una volta scrive i dati del compressore1 e una volta scrive i dati della copia nell'ordine che viene impartito dal kernel.

eh? ma che senso ha? lo scheduler c'e' gia a monte (lo scheduler di I/O del kernel), introdurre un secondo scheduling nel controller (o addirittura nei dischi), non solo sarebbe un macello (come fa lo scheduler a sapere da quale processo arrivano le operazioni di lettura/scrittura?) ma sarebbe anche deleterio per le prestazioni (se lo scheduling lo fa gia il kernel, ridondarlo crea solo overhead senza alcun beneficio). Inoltre l'esempio dello scheduler dei processi e' fuorviante, in quanto anche con i dischi la situazione e' la medesima, in entrambi i casi c'e' uno scheduler software (nel caso del processore lo scheduler dei processi e nel caso dei dischi lo scheduler di I/O), quindi la differenza dov'e'?

Se è questa la questione suppongo che il buffering sia la soluzione comunque migliore in efficienza proprio perchè elimina i salti della testina dal file1 al file2 alla stessa frequenza con cui avviene tra il processo1 e il processo2 nel kernel.

IMVHO
Gio

non solo il buffering, ma anche l'NCQ migliora di molto le prestazioni sotto questo aspetto

[masalapianta]

what is the point of this thread, seriously ?

la scoperta dell'acqua calda (o della patata lessa se preferisci)

[Mario Vanoni]

[..]
disattivavano la on-board memory, possibile allora,
[..]
il disco fa poi quello che vuole lui e quando vuole lui.

Ma perché allora in certi post ti vanti di avere HD con tanti mb di memory onboard? Dicendo addirittura che non parli con chi non è così all'avanguardia?
Il problema della memoria onboard serve proprio per limitare questa sensazioni di mancata "contemporaneità" di due scritture.
Per fare quello che chiedi forse serve quello che critichi sempre, le tanto bistrattate tecnologie software fatte da non geni
Per esempio un RAID 0 con più dischi potrebbe in alcune occasioni ovviare al fatto che l'hd è unico e come ti hanno detto se scrive una cosa non può "contemporaneamente" (metto tra virgolette perché dipende anche dal numero di testine e piatti) scriverne un'altra, la quale si mette in coda. Gli scheduler I/O servono proprio per gestire queste "code".
Alcuni consigliano, tramite trucchi di cui non mi sono mai interessato, di fare tante partizioni quanti sono i piatti dell'HD (facendo riferimento ai blocchi e quindi sapendo esattamente le dimensioni di ciascun piatto), in modo da migliorare le prestazioni? Altri ancora consigliano di prendere HD da terabyte ed usarne un decimo, per migliorare i "tempi morti" di riposizionamento delle testine, tipo qui
http://www.tomshw.it/storage.php?guide=20090319

Insomma, puoi migliorare le prestazioni del tuo hard-disk di un poco, ma con soluzioni che hai sempre detto inutili al giorno d'oggi.

Spero di non aver detto tante bischerate, è un settore di cui non mi sono mai occupato più di tanto

Corrado, hai ragione, ma ...

Test riproducibile, 114 files, 5.5GB insieme, trasferta tra due HD moderni:

time mv * /hd2/dir
1m57.316s
un programma che scrive allo stesso tempo su HD stalla

time ls | while read f; do mv $f; sync ; sync ; sync; done
2m25.811s
un programma che scrive allo stesso tempo su HD viaggia

Se il 90% della memoria sono pieni del primo programma,
il secondo la colma al 100%,
pero` il secondo programma aspetta il suo turno e stalla.

Con sync(1) obblighi logica/memory HD ad aggiornarsi subito.

Per questo ai tempi su HD SCSI si poteva disattivare la memoria,
allora solo 16kB, il nuovo WD2002FYPS ne avra` 64MB.

Per un errore _mio_ nel programmare la UPS della seconda macchina,
tre black-out di seguito della cara ENEL,
sono svaniti nel nulla 56 files su 22197,
erano in memoria ...

[murdock]

Iniziamo considerando che se un hard disk ha due piatti e quattro testine (sopra e sotto), queste ultime non si muovono comunque in modo individuale ma in blocco.
Quindi se la prima testina scrive in un punto sul primo piatto superiore, le altre testine sono posizionate nello stesso punto nei rispettivi piatti (superiore ed inferiore).
Ergo, se le rimanenti tre testine, trovano occupato lo spazio dove si trovano, scrive solo la prima e le altre aspettano una "situazione più favorevole".
Un raid0 limita molto questa possibilità dato che elimina questo vincolo utilizzando più dischi a sé stanti ognuno poi con la propria cache.
Dipende da come è progettata la logica del disco, normalmente, che io sappia, il buffer di memoria dell'hard disk dovrebbe venir diviso per il numero di accessi disco,
quello che poi fa la meccanica viene in secondo piano.
Teoricamente, due operazioni di scrittura sullo stesso disco non dovrebbero (se ho capito bene) l'una aspettare il termine dell'altra ma,
dovrebbero funzionare entrambe anche se più lentamente.
Non escludo comunque che di mezzo ci sia il controller hdd oppure qualche configurazione particolare dello scheduler I/O che genera questo comportamento.

Saluti,
MuRdOcK

[Mario Vanoni]

Iniziamo considerando che se un hard disk ha due piatti e quattro testine (sopra e sotto), queste ultime non si muovono comunque in modo individuale ma in blocco.
Quindi se la prima testina scrive in un punto sul primo piatto superiore, le altre testine sono posizionate nello stesso punto nei rispettivi piatti (superiore ed inferiore).
Ergo, se le rimanenti tre testine, trovano occupato lo spazio dove si trovano, scrive solo la prima e le altre aspettano una "situazione più favorevole".
Un raid0 limita molto questa possibilità dato che elimina questo vincolo utilizzando più dischi a sé stanti ognuno poi con la propria cache.
Dipende da come è progettata la logica del disco, normalmente, che io sappia, il buffer di memoria dell'hard disk dovrebbe venir diviso per il numero di accessi disco,
quello che poi fa la meccanica viene in secondo piano.
Teoricamente, due operazioni di scrittura sullo stesso disco non dovrebbero (se ho capito bene) l'una aspettare il termine dell'altra ma,
dovrebbero funzionare entrambe anche se più lentamente.
Non escludo comunque che di mezzo ci sia il controller hdd oppure qualche configurazione particolare dello scheduler I/O che genera questo comportamento.

Saluti,
MuRdOcK

Ho l'ultima fase del test che viaggia da >14 giorni.

Decompressori su 2 CPU e due HD,
l'uno dall'alto al basso, l'altro dall'ultimo file in su.

sar 1 dice:
00:00:01 CPU %user %nice %system %iowait %steal %idle
20:39:01 all 76.42 0.00 2.12 17.43 0.00 4.03

secondo man sar
%iowait
Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.

Quindi i CPU stallano per aspettare che il disco si [ri]svegli.

[slucky]

Lucio ha scritto:

e sempre se ci tenete alla salute ... evitate di comprare Seagate e Maxtor almeno fino a che non torneranno a fare un assistenza degna di questo nome!

concordo in pieno, con i maxtor ho avuto solo problemi, invece consiglio vivamente i western digital, sono delle vere roccie affidabili è precisi, ne ho ancora uno perfettamente funzionante malgrado abbia più di 12 anni, che come sappiamo da un punto di vista informatico è come dire di un'età giurassica.....

[Blallo]

Lucio ha scritto:

e sempre se ci tenete alla salute ... evitate di comprare Seagate e Maxtor almeno fino a che non torneranno a fare un assistenza degna di questo nome!

concordo in pieno, con i maxtor ho avuto solo problemi, invece consiglio vivamente i western digital, sono delle vere roccie affidabili è precisi, ne ho ancora uno perfettamente funzionante malgrado abbia più di 12 anni, che come sappiamo da un punto di vista informatico è come dire di un'età giurassica.....

quoto in pieno
ho un hd esterno western digital...139 € 500 GB, allo stesso prezzo forse avrei trovato più capienza ma mi sta dando soddisfazioni inimmaginabili come prestazioni!

[Luci0]

Devo dire che con i Maxtor forse ho avuto fortuna ... ma attualmente i resi vengono effettuati in modo veramente vergognoso ... i refurbished sono dei veri tarocchi ... statene alla larga ... Se per caso vi si rompe un disco Maxtor o Seagate in garanzia usatelo come fermacarte ...

[slucky]

Se per caso vi si rompe un disco Maxtor o Seagate in garanzia usatelo come fermacarte ...

anche questo buono a sapersi Lucio

Offtopic: a proposito Lucio complimenti per il look da vero frikkettone!!...con un chitarrone fender, un camicione pacifista in stile figlio dei fiori, ti ci vedrei proprio su un palco stile Woodstock a menar fendenti musicali a destra e manca....
Grande Lucio!

[masalapianta]

Ho l'ultima fase del test che viaggia da >14 giorni.
...
secondo man sar
%iowait
Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.

Quindi i CPU stallano per aspettare che il disco si [ri]svegli.

cioe' hai sprecato 14 giorni per scoprire cos'e' l'iowait (non ti sei mai chiesto cosa fosse "%wa" in top?) e che in un disco il tempo di accesso non e' zero e la velocita' di trasferimento non e' infinita?

[Mario Vanoni]

Ho l'ultima fase del test che viaggia da >14 giorni.
...
secondo man sar
%iowait
Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.

Quindi i CPU stallano per aspettare che il disco si [ri]svegli.

cioe' hai sprecato 14 giorni per scoprire cos'e' l'iowait (non ti sei mai chiesto cosa fosse "%wa" in top?) e che in un disco il tempo di accesso non e' zero e la velocita' di trasferimento non e' infinita?

Hai ragione, ma ...

Tu sei moderno, quindi osservi continuamente top(1),
magari con s (Change delay from 3.0 to: ) messo a 0.1 secondi.

Dai tempi di AT&T SVR3 crontab(1) mi lancia ogni minuto "/usr/lib/sa/sa1 1 1 &",
fa un file giornaliero e mantiene i giorni precedenti, quanti a tua scelta (a me 7 bastano).

Da questi ricavo l'attivita` dei CPU e _quando_ stallano dovuto a iowait.
E registro sul minuto quando uno o due programmi partono e quando finiscono.
sar -P ALL | less per oggi oppure sar -P ALL -f /var/log/sa/saDD | less per il giorno DD
Con programmi che durano giorni, molto piu` pratico di time(1).

[davide77]

Mario, IMVHO il tuo problema è abbastanza comune (io ce l'ho sia a casa che al lavoro) con i dischi ide/sata e una possibile spiegazione può essere che il cp/mv lavora tantissimo in DMA, quindi lascia fare a controller/dischi sgravando la cpu mentre i programmi di compressione leggono il blocco di dati che gli serve, lo comprimono e ne richiedono un'altro. In questo modo "perdono" di priorità rispetto al controller.

Io tra l'altro ho rimesso lo scheduler ad Anticipatory dal cfq di default perché a mio avviso funziona meglio per le mie esigenze (tanto i dischi vanno da schifo lo stesso ).