Re: [OT] orario continuamente fuori sincrono.
On 21/09/2012 13:20, Mauro wrote: 2012/9/16 Mauromrsan...@gmail.com: 2012/9/15 Lorenzo Berettalory.fu...@infinito.it: On 15/09/2012 15:20, Mauro wrote: Ho due server, in ciascuno dei quali gira ntp. Inizialmente in ciascuno ho settato in modo corretto l'orario di sistema dopodiche' ho fatto hwclock --systohc --utc. Sembra tutto a posto. Succede pero' che in uno dei due server l'ntp daemon va in crash e non capisco il perche'. Ogni volta che succede noto che l'orario del server va di molto fuori sincrono, talvolta anche di 1 ora. Immagino che la causa del crash di ntp sia questa e cioe' l'orario del server va avanti di un tanto che ntp non riuscendo piu' a sincronizzarlo va in crash. Ora mi chiedo come mai, nonostante l'hardware clock sia corretto, l'orario improvvisamente vada fuori sincrono. Se anche ntp andasse in crash per conto suo senza motivo, comunque non capisco perche' l'orario del server me lo ritrovi un'ora avanti, forse un problema con la batteria cmos? Avete qualche idea? Su ntpd al momento no, ma per quel che riguarda la batteria cmos si può verificare facilmente se è lei -- disabiliti ntpd, sincronizzi l'ora a manina con ntpdate, gli dai un po' di tempo e vedi se l'orologio di sistema rimane +o- sincronizzato (magari sballando di qualche secondo) oppure va per i fatti suoi. Certo che e' strano, ntpd gira su due nodi di un cluster i quali hanno lo stesso hardware e lo stesso software, in pratica sono due gemelli. Ntpd va in crash solo in uno dei due, non capisco. Sembra un bug del kernel. http://my.opera.com/marcomarongiu/blog/2010/08/18/debugging-ntp-again-part-4-and-last Verificato che è quello? Funziona disable kernel? Nel caso un rimedio temporaneo potrebbe essere openntpd -- è meno preciso di ntp, e la versione per linux è mantenuta solo da alcune distro (debian e arch che io sappia :), ma 1. è semplicissimo da usare, e 2. il motivo per cui è meno preciso è che fa il minimo indispensabile per sincronizzare l'ora: la versione upstream (*) chiama solo adjtime, non adjtimex -- incrociando le dita, è probabile che riesca a non incoccare in quel benedetto bug. (*) solo quella per linux, che è datata; di recente debian ha aggiornato importando a manina alcune migliorie che erano rimaste confinate a openbsd. -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505dbddc$0$17949$4fafb...@reader1.news.tin.it
Re: [OT] orario continuamente fuori sincrono.
2012/9/22 Lorenzo Beretta lory.fu...@infinito.it: On 21/09/2012 13:20, Mauro wrote: 2012/9/16 Mauromrsan...@gmail.com: 2012/9/15 Lorenzo Berettalory.fu...@infinito.it: On 15/09/2012 15:20, Mauro wrote: Ho due server, in ciascuno dei quali gira ntp. Inizialmente in ciascuno ho settato in modo corretto l'orario di sistema dopodiche' ho fatto hwclock --systohc --utc. Sembra tutto a posto. Succede pero' che in uno dei due server l'ntp daemon va in crash e non capisco il perche'. Ogni volta che succede noto che l'orario del server va di molto fuori sincrono, talvolta anche di 1 ora. Immagino che la causa del crash di ntp sia questa e cioe' l'orario del server va avanti di un tanto che ntp non riuscendo piu' a sincronizzarlo va in crash. Ora mi chiedo come mai, nonostante l'hardware clock sia corretto, l'orario improvvisamente vada fuori sincrono. Se anche ntp andasse in crash per conto suo senza motivo, comunque non capisco perche' l'orario del server me lo ritrovi un'ora avanti, forse un problema con la batteria cmos? Avete qualche idea? Su ntpd al momento no, ma per quel che riguarda la batteria cmos si può verificare facilmente se è lei -- disabiliti ntpd, sincronizzi l'ora a manina con ntpdate, gli dai un po' di tempo e vedi se l'orologio di sistema rimane +o- sincronizzato (magari sballando di qualche secondo) oppure va per i fatti suoi. Certo che e' strano, ntpd gira su due nodi di un cluster i quali hanno lo stesso hardware e lo stesso software, in pratica sono due gemelli. Ntpd va in crash solo in uno dei due, non capisco. Sembra un bug del kernel. http://my.opera.com/marcomarongiu/blog/2010/08/18/debugging-ntp-again-part-4-and-last Verificato che è quello? Funziona disable kernel? Nel caso un rimedio temporaneo potrebbe essere openntpd -- è meno preciso di ntp, e la versione per linux è mantenuta solo da alcune distro (debian e arch che io sappia :), ma 1. è semplicissimo da usare, e 2. il motivo per cui è meno preciso è che fa il minimo indispensabile per sincronizzare l'ora: la versione upstream (*) chiama solo adjtime, non adjtimex -- incrociando le dita, è probabile che riesca a non incoccare in quel benedetto bug. Avevo installato openntp al posto di ntp e purtroppo si e' ancora verificato il problema, mi sono ritrovato l'orario dei due server avanti di ben due ore. Ora ho rimesso ntp abilitando l'opzione disable kernel, spero sia la volta buona perche' non so piu' che pesci pigliare. Certo e' che se fosse un bug del kernel la cosa e' molto fastidiosa. -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE17a0VkUf0zMMdND=jzrqrbwqyqoukqxgavteduiwkgwqa...@mail.gmail.com
Write Cache e RAID
Un ciao a tutta la lista. Ho una domanda abbastanza precisa sulle cache e il rischio di perdita dati in caso di calo di tensione. (la pongo in anticipo perché il sistema sarà preparato tra qualche giorno) Il sistema in questione è un piccolo file server domestico che ha perlopiù funzione di storage su 3 dischi in RAID 5 software con mdadm e con il sistema operativo su un disco a parte. Le scritture sono molto rare e riguardano sempre dati di cui rimarrà una copia sul disco di sistema per un po' di tempo dopo l'archiviazione sul RAID, quindi perdere i dati mentre sono in fase di scrittura non costituisce un danno. Ora se non erro esiste la write cache del singolo disco e la write cache del filesystem (in ram, fatta dal sistema operativo). Il fs dell'archivio penso che sarà un ext4 con journaling abilitato e montato con noatime. Volevo sapere l'effetto di un calo di tensione durante un operazione di scrittura sul RAID e come può variare magari disabilitando l'una o l'altra delle cache (magari pone un rischio maggiore rispetto all'altra). E' possibile la corruzione dei dati che già si trovano sul disco? La corruzione dell'intero filesystem con conseguente perdita di tutto il contenuto? O anche usando un RAID perdo solo i dati in fase di scrittura? (dei quali ho già scritto ho poco interesse visto che ne esiste sempre una copia). -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505df8a5.3020...@gmail.com
Re: Write Cache e RAID
Ciao Davide ! In effetti il discorso della cache in scrittura è da sempre un discorso delicato. Non è un caso che i controller RAID abbiamo una batteria tampone sul controller stesso per evitare che la cache onboard (spesso generosa) vada persa in caso di poweroff non regolare. Trattandosi di un RAID md: Iniziamo ad analizzare la cache fisica dei singoli dischi: Se si presentasse una perdita di consistenza su un singolo disco, la presenza di un RAID5 sicuramente aiuta, proprio per la sua natura di presentare dei blocchi di ECC che verificano la correttezza dei blocchi distribuiti (ed eventualmente li correggono entro certi limiti). Questo a livello di device. La perdita di informazione relativa alla cache del FS non presenta alcuna differenza relativamente alla presenza o meno di md. Ovviamente se si può evitare di perdere la consistenza è meglio ma probabilmente se lavori su un sistema che lavora in condizioni critiche (poweroff frequente) allora conviene ridurre al minimo la cache di sistema sacrificando un po le prestazioni. CIAO Luca -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120922183804.m52...@corep.it
Re: Write Cache e RAID
Il 22/09/2012 20:45, dea ha scritto: Ciao Davide ! In effetti il discorso della cache in scrittura è da sempre un discorso delicato. Non è un caso che i controller RAID abbiamo una batteria tampone sul controller stesso per evitare che la cache onboard (spesso generosa) vada persa in caso di poweroff non regolare. Trattandosi di un RAID md: Iniziamo ad analizzare la cache fisica dei singoli dischi: Se si presentasse una perdita di consistenza su un singolo disco, la presenza di un RAID5 sicuramente aiuta, proprio per la sua natura di presentare dei blocchi di ECC che verificano la correttezza dei blocchi distribuiti (ed eventualmente li correggono entro certi limiti). Questo a livello di device. La perdita di informazione relativa alla cache del FS non presenta alcuna differenza relativamente alla presenza o meno di md. Ovviamente se si può evitare di perdere la consistenza è meglio ma probabilmente se lavori su un sistema che lavora in condizioni critiche (poweroff frequente) allora conviene ridurre al minimo la cache di sistema sacrificando un po le prestazioni. CIAO Luca Grazie Luca, fin troppo preciso e disponibile. La situazione del sistema non è realmente critica, sono anni che non si presenta un calo di tensione, così come sono anni che non si rompe un disco. Con il RAID mi tutelo dal secondo ma ero preoccupato di espormi troppo al primo, rendendo quindi vano parte del lavoro. Non sono sicuro di avere capito bene ma, correggimi se sbaglio, l'unico rischio nel mio caso sarebbe presentato dalla cache dei dischi perché può causare perdita di consistenza per più di un disco sullo stesso blocco. E anche in quel caso non sarebbe molto diverso dall'avere un disco solo, ma dato che mi sono premurato di avere un RAID per tenere al sicuro i miei dati, è anche il caso che riduca anche il rischio di questo inconveniente. Per le prestazioni dei dischi in mancanza della loro cache non mi preoccupo tantissimo perché fanno da archivio a grossi file la cui lettura non richiede grande velocità, e come ho detto il sistema operativo non graverà sul RAID trovandosi su un SSD a parte. Correggimi pure se ho scritto qualcosa di sbagliato ! Davide -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505e103b.1060...@gmail.com
Re: Write Cache e RAID
Ma a questo punto investire 100 euro in un ups di basso livello??
Re: Write Cache e RAID
Il 22/09/2012 23:10, Luca Costantino ha scritto: Ma a questo punto investire 100 euro in un ups di basso livello?? Contando che non sarebbe stato acceso 24/7 le probabilità di incontrare un calo di tensione erano già abbastanza basse, e volevo capire se era davvero necessario aggiungere altra roba o se quello che avevo poteva bastare per le mie esigenze. -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505e3c8d.2020...@gmail.com
