Newsgroup: it.comp.os.linux.sys
Titolo: ext4_lookup: deleted inode referenced

Premessa: devo far partire un bel fsck per risolvere.
 
La maintenance window più vicina è questo weekend.
 
Nel frattempo, posso sistemare in qualche modo ?
AFAIK, fsck va eseguito con FS smontato e non posso smontarlo senza far incazzare mille-mila clienti (è la partizione con i dati) e un fsck su 100GB potrebbe richiedere una buona mezzora/ora


  Questo è il caso tipico in cui si usa una qualunque delle diverse
piattaforme di ridondanza/mirroring/RAID>0/ecc..  Pensare di dotarsi di
un estintore quando si sente odore di bruciato e si è immersi nel fumo
di solito è troppo tardi.
 
  Per me hai due scelte:
 
1) incroci le dita (anche quelle dei piedi) e aspetti il finesettimana
prima di fare non solo un fsck, ma di implementare un qualsiasi
meccanismo di ridondanza che permetta di avere un
FS/copia/snapshot/mirror capace di subentrare immediatamente al FS
primario in caso questo incorra in errori o guasti;
2) se ritieni la probabilità di un guasto disastroso troppo elevata o il
possibile danno conseguente inaccettabile se pesato contro la
possibilità di peggiorare le cose con un tale intervento, implementi
adesso un meccanismo di ridondanza temporaneo.
 
  Altro non mi viene in mente senza un qualche tempo di interruzione del
servizio e senza poter contare su un sistema gemello che possa
subentrare, che do per scontato non esista e che non puoi implementare
da come hai esposto il problema.
 
  Nel caso (2), supponendo che il FS primario non sia un RAID/LVM/FS con
snapshot o altro simile, quello che puoi fare è di collegare un
dispositivo di massa sul quale riversare i dati di quello adesso
on-line, e prepararti per poter all'occorrenza mettere manualmente
on-line questo secondo dovesse il primo saltare.  Quindi predisponi una
sincronizzazione tra i due filesystem ad intervalli regolari, ad esempio
mettendo un job in cron per la mezzanotte, e nel finesettimana, dopo
aver fatto il fsck, implementi quello che avresti dovuto fare il giorno
prima di mettere on-line un sistema di produzione per "mille-mila
clienti": metti tutto in RAID/LVM/btrfs...
 
  Almeno i backup li hai fatti, giusto?
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

   Almeno i backup li hai fatti, giusto?
 
Si. Ed è questo che mi da sicurezza. Il backup copia *tutto* il server, durante la copia si verificano solo 158 errori di lettura su singoli file (inutili, sono cache di vari CMS), molto probabilmente associati agli inodes in questione. Posso benissimo buttarli via tutti.

 Si. Ed è questo che mi da sicurezza. Il backup copia *tutto* il server, durante la copia si verificano solo 158 errori di lettura su singoli file (inutili, sono cache di vari CMS), molto probabilmente associati agli inodes in questione. Posso benissimo buttarli via tutti.
 
Oltretutto tutti riferiti ad un ex cliente. Posso segare tutto senza indugi.

 Non ti seguo proprio....
 
Il suo pensiero, se non l'ho interpretato male, si riferiva ad un sistema senza
RAID, ovvero creato sulla base di un solo disco. Personalmente ritengo che sei
nel guano, in quanto ci sono millemila motivi per cui hai un problema simile,
e spero per te che tu riesca a risolverli. Sicuramente, aspettare il fine
settimana per farlo (oggi è 9 Maggio, Lunedì) non è una buona idea
 
Enrico

 settimana per farlo (oggi è 9 Maggio, Lunedì) non è una buona idea
 
Ma io ho tutto sotto RAID (hw, 6), non è un sistema mono-disco. 
Oltretutto il RAID non tutela dalla corruzione del filesystem, a dire il vero, al raid interessa meno di niente del filesystem che ci sta sopra. Replica i blocchi, non il filesystem.
 
Comunque ho risolto: ho smontato il filesystem, eseguito fsck e rimontato. 15 minuti circa.
 
Volevo solo sapere se in questi casi ci siano alternative fattibili con il filesystem online.
 
Quali sono i mille-mila motivi che possono portare ad un problema del genere?

 Quali sono i mille-mila motivi che possono portare ad un problema del genere?
 
Ad esempio problemi di parità con la RAM
 
Enrico

 Ad esempio problemi di parità con la RAM
 
Come lo verifico ?

 Come lo verifico ?
 
Memtest86 questo fine settimana sarà tuo amico :)
 
Enrico

 Come lo verifico ?
 
Oltretutto la stessa cosa si presenta anche su un altro server, completamente scollegato dal primo.
 
Io credo si sia trattato, in ambo i casi, di uno shutdown non proprio "gentile" e contestuale fsck saltato in fase di boot.

 Volevo solo sapere se, nel frattempo, ci fosse un modo per "ripulire" il FS a caldo.
 
  Questo contraddice quello che avevi scritto in precedenza:
 
«non posso smontarlo senza far incazzare mille-mila clienti (è la
partizione con i dati)»


 Volevo solo sapere se in questi casi ci siano alternative fattibili con il filesystem online.
 
  L'unica cosa che mi viene in mente adesso è di verificare la
leggibilità dei vari file, e se qualche file produce degli errori e ne
ho un backup lo cancello e ne ricopio il contenuto dal backup.


 partizione con i dati)»
 
Non lo contraddice.
Significa che li ho fatti incazzare.
Fan due fatiche, prima o poi si scazzeranno.
 
Stavo appunto cercando un workaround. Non c'è? Benissimo, li faccio incazzare e faccio comunque l'intervento.

 ho un backup lo cancello e ne ricopio il contenuto dal backup.
 
I file in questione non erano leggibili ne gestibili in alcun modo. Anche un "rm" non andava a buon fine. Effettivamente l'fsck eseguito in seguito ha rimosso i riferimenti agli inode in questione, ripulendo ben bene tutto.
Il backup di questa notte non ha segnalato più alcun errore durante la copia.
 
Ho lo stesso problema su altro server, dove oltretutto ricevo errori di tipo "Stale NFS handle" o cose simili. Peccato che non ho un volume NFS :)
 
Farò la stessa procedura tra oggi e domani: smonto, fsck, rimonto.
 
Escludo un problema alla RAM, sono tutte ECC e due server completamente differenti, sia come annata che come modello (non vuol dire niente), sia come vendor della RAM.
Nulla è impossibile, ma avere, in meno di 1 mese, due problemi identici su due server diversi con svariati anni diversi di servizio (uno è del 2009, l'altro del 2012) mi lascia alquanto dubbioso. Avessero le stesse ore di servizio, ci potrebbe anche stare.
 
Per me è stato un qualche reboot forzato tramite SysRq 
Ho delle procedure di emergenza che lo fanno in automatico in determinate circostanze dove sarebbe impossibile sopravvivere e, anche sopravvivendo, sarebbe poi impossibile accedere da remoto (del tipo: OOM che killa a destra e a manca, compreso ssh, che puntualmente capita di notte e dovrei svegliarmi a sistemare). Il reboot selvaggio mi fa dormire fino al giorno dopo per poi fixare e riattiva tutti i servizi.

 Uso sempre RAID-6
 
Questa non è sempre una buona idea, sappilo
 
Enrico

 Questa non è sempre una buona idea, sappilo
 
Lo so, ma è la meno peggio in buona parte dei casi dove le performance in scrittura non sono critiche.
 
Protegge da 2 dischi rotti alla volta, a differenza di tutti gli altri livelli RAID mono-cifra.
 
Una soluzione analoga potrebbero essere dei RAID-5/6 accorpati con LVM
O dei RAID-1 a 3 dischi, sempre accorpati con LVM (non mi pare esistano controller che fanno RAID-10 con "coppie" e 3 dischi)