Re: [OT] idle3-tools, mi serve?
Il 27/09/2015 12:13, mauro altemica s.r.l. ha scritto: Il giorno 26/set/2015, alle ore 19:17, fran...@modula.net ha scritto: La cache dei dischi Sata in scrittura di solito la si tiene disabilitata e quella in lettura abilitata. la cache in scrittura puo’ essere abilitata e avere la certezza della coerenza dei dati se hai una alimentazione adeguata e garantita: i server seri, p.es., hanno una batteria tampone che tiene in vita la cache dei controller proprio per aumentare le performance e contemporaneamente avere garanzia in caso di caduta di alimentazione. Per noi poveracci, un approccio simile e’ usando un gruppo di continuita’ buonino e comunque, a meno di necessita’ effettive, e’ meglio non abusare di questa tecnologia. Mauro, se avevi seguito tutto il thread potevi vedere che quanto dici tu era già stato scritto ma il problema affrontato non è la coerenza dei dati ma capire quali eventi sul bus Sata richiedono l'intervento della meccanica dei dischi. Purtroppo per accorciare le risposte a volte è utile tagliare gli argomenti a cui non si risponde e quindi se non si leggono tutti i messaggi del thread perde un pò il filo del discorso. Luciano
Re: [OT] idle3-tools, mi serve?
> Il giorno 26/set/2015, alle ore 19:17, fran...@modula.net ha scritto: > > La cache dei dischi Sata in scrittura di solito la si tiene disabilitata e > quella in lettura abilitata. la cache in scrittura puo’ essere abilitata e avere la certezza della coerenza dei dati se hai una alimentazione adeguata e garantita: i server seri, p.es., hanno una batteria tampone che tiene in vita la cache dei controller proprio per aumentare le performance e contemporaneamente avere garanzia in caso di caduta di alimentazione. Per noi poveracci, un approccio simile e’ usando un gruppo di continuita’ buonino e comunque, a meno di necessita’ effettive, e’ meglio non abusare di questa tecnologia. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [OT] idle3-tools, mi serve?
Il 26/09/2015 11:02, tarqui ha scritto: Quando si effettua una write e il sistema ci comunica che è andata a buon fine non necessariamente il dato è scritto effettivamente su disco. Anzi: di solito non lo è. Dipende dalla condizione dei buffer di i/o, e dal parametro "commit" in fstab "commit" e forse da altre cose che potrebbero anche non essere sotto il diretto controllo del kernel, come ad esempio in caso di dischi di rete, controller raid hardware con cache di grandi dimensioni e batteria tampone e chissà cos'altro. In un sistema normalino con dischi Sata il comando commit viene eseguito almeno ogni 5 secondi e questo dovrebbe metterti al riparo dal problema dell'idle3. ho già provato con commit alto, ma il lampeggio ogni due secondi c'è comunque. http://www.archlinux.it/forum/viewtopic.php?f=6=396=30 https://bbs.archlinux.org/viewtopic.php?id=89204 ... la spia hdd collegata alla scheda madre credo indichi l'attività del connettore sata, quindi una comunicazione fisica con l'hd. quindi l'unico buffer in gioco dovrebbe essere nella cache del disco. o sbaglio? dove viene gestito il buffer per il commit ritardato? a livello ram o sulla cache del disco? o dove altrimenti? La cache dei dischi Sata in scrittura di solito la si tiene disabilitata e quella in lettura abilitata. Il commit provoca provoca una scrittura diretta sui disco dei dati contenuti del buffer di i/o del sistema che si trova in ram, a meno di non avere un controller con cache protetta da una batteria: in questo secondo caso il commit crede di avere scritto su disco non appena i dati sono nella cache del controller. Puoi imporre un commit con il comando sync, che sincronizza il file system con il buffer di i/o del sistema. La luce che si accende ogni due secondi può indicare attività in scrittura ma anche attività in lettura. In quest'ultimo caso potrebbe trattarsi anche di lettura della sola cache se il contenuto richiesto si trova già nella cache del disco, senza coinvolgimento della meccanica. e anche se il disco non fa questo gran baccano, non mi sembra di averlo mai sentito ripartire. quindi non penso si sia mai fermato. il disco ha qualche anno, ma non mi sembra che il valore dei cicli (+ di 199000) possa essere stato raggiunto solo con riavvii vari. con # watch 'smartctl -A /dev/sda | grep 193' ho provato adesso una sospensione e ripresa e il valore incrementa correttamente di 1. diversamente è fisso. Credo che il valore si incrementi appena il disco inizia una sospensione, non è necessario che la porti a termine. Tieni conto che anche i settaggi VCPI influiscono sulla attivazione e disattivazione delle periferiche. la mia ipotesi è che il problema sia stato risolto, e il valore alto è stato raggiunto prima che lo fosse. ma siccome non ho i modelli indicati come affetti dal problema nella descrizione del pacchetto idle3-tools, può essere che fisicamente il mio disco non si sia mai fermato. quindi forse il valore indicato è sbagliato, ma fisicamente non ho mai rischiato di fondere un bel niente. Però: se il sistema è inattivo, nel senso che nessuno ha letto o scritto niente negli ultimi 5 secondi, il comando commit che fà? Si fa sentire dal disco che può quindi resettare l'idle counter oppure no? Se qualcuno ha voglia di fare un test Luciano ehm, credo esuli le mie attuali capacità. grazie per tutte le informazioni. Roberto Luciano
[OT] idle3-tools, mi serve?
mi scuso in anticipo per l'ot. e ringrazio a chi vorrà darmi delucidazioni. sto cercando di capire se mi può servire il pacchetto idle3-tools e a quale problema si riferisca. riporto da http://idle3-tools.sourceforge.net/ If you have a Western Digital EADS or EARS drive, please check you SMART information before it's too late : If the Load cycle count exceeds 1000, you're probably affected by the idle3 timer problem. dunque, 1. il mio hd è WD10EZRX-00A8LB0 quindi EZRX e dunque NON dovrei avere il problema. giusto? 2. smartctl riporta per il mio hd 199194, quindi ho ugualmente il problema? nella descrizione del pacchetto (sul repository) viene riportato che il disco si dovrebbe erroneamente fermare *every eight seconds* di inattività. se non ricordo male (e la spia del mio hdd lo conferma) esiste uno storico problema dell'accesso al disco ogni 2 secondi (riguardante kernel o ext4). quest'ultimo non dovrebbe compensare il problema del timer impedendo di fatto l'arresto del disco? ripeto quanto in incipit. grazie per qualsiasi delucidazione. Roberto
Re: [OT] idle3-tools, mi serve?
Il 25/09/2015 17:56, tarqui ha scritto: mi scuso in anticipo per l'ot. e ringrazio a chi vorrà darmi delucidazioni. sto cercando di capire se mi può servire il pacchetto idle3-tools e a quale problema si riferisca. riporto da http://idle3-tools.sourceforge.net/ If you have a Western Digital EADS or EARS drive, please check you SMART information before it's too late : If the Load cycle count exceeds 1000, you're probably affected by the idle3 timer problem. dunque, 1. il mio hd è WD10EZRX-00A8LB0 quindi EZRX e dunque NON dovrei avere il problema. giusto? 2. smartctl riporta per il mio hd 199194, quindi ho ugualmente il problema? nella descrizione del pacchetto (sul repository) viene riportato che il disco si dovrebbe erroneamente fermare *every eight seconds* di inattività. se non ricordo male (e la spia del mio hdd lo conferma) esiste uno storico problema dell'accesso al disco ogni 2 secondi (riguardante kernel o ext4). quest'ultimo non dovrebbe compensare il problema del timer impedendo di fatto l'arresto del disco? ripeto quanto in incipit. grazie per qualsiasi delucidazione. Roberto Quando si effettua una write e il sistema ci comunica che è andata a buon fine non necessariamente il dato è scritto effettivamente su disco. Anzi: di solito non lo è. Dipende dalla condizione dei buffer di i/o, e dal parametro "commit" in fstab "commit" e forse da altre cose che potrebbero anche non essere sotto il diretto controllo del kernel, come ad esempio in caso di dischi di rete, controller raid hardware con cache di grandi dimensioni e batteria tampone e chissà cos'altro. In un sistema normalino con dischi Sata il comando commit viene eseguito almeno ogni 5 secondi e questo dovrebbe metterti al riparo dal problema dell'idle3. Però: se il sistema è inattivo, nel senso che nessuno ha letto o scritto niente negli ultimi 5 secondi, il comando commit che fà? Si fa sentire dal disco che può quindi resettare l'idle counter oppure no? Se qualcuno ha voglia di fare un test Luciano
