Soluzione 1:
Il tempo fsck predefinito di 180 giorni è una soluzione alternativa per il difetto di progettazione che ext3 non supporta un controllo di coerenza online. La vera soluzione è trovare un filesystem che lo supporti. Non so se qualche filesystem maturo lo faccia. È una vera tragedia. Forse btrfs ci salverà un giorno.
Ho risposto al problema del tempo di inattività di più ore a sorpresa da fsck eseguendo riavvii programmati con un fsck completo come parte della manutenzione standard. Questo è meglio che imbattersi in un danneggiamento minore durante le ore di produzione e trasformarlo in una vera e propria interruzione.
Gran parte del problema è che ext3 ha un fsck irragionevolmente lento. Sebbene xfs abbia un fsck molto più veloce, utilizza troppa memoria per le distribuzioni per incoraggiare xfs per impostazione predefinita su filesystem di grandi dimensioni. Tuttavia, sulla maggior parte dei sistemi questo non è un problema. Il passaggio a xfs consentirebbe almeno un fsck ragionevolmente veloce. Ciò potrebbe rendere più semplice la pianificazione dell'esecuzione di fsck come parte della normale manutenzione.
Se stai usando RedHat e stai pensando di usare xfs, devi stare attento a quanto fortemente scoraggiano l'uso di xfs e al fatto che probabilmente ci sono poche persone che usano xfs sul kernel che stai usando.
La mia comprensione è che il progetto ext4 ha l'obiettivo di migliorare almeno in parte le prestazioni di fsck.
Soluzione 2:
Direi che questo è solo un altro motivo per cui i server di produzione non dovrebbero funzionare da soli e avere sempre un backup caldo/freddo o prendere parte a un cluster a due nodi. In questi giorni di virtualizzazione, puoi facilmente avere un server principale fisico e un server virtuale, che è solo una copia del server fisico eseguito ogni X giorni, pronto a subentrare.
Oltre a questa risposta non così utile, direi che dovresti bilanciare l'importanza dei tuoi dati ... Se questo è solo un nodo del cluster, saltalo. Se si tratta di un server web senza backup di un client, potresti voler pianificare in anticipo la prossima volta :-)
Soluzione 3:
Dipende .. Ad esempio, abbiamo avuto un server inattivo per manutenzione ordinaria che eseguiva uno stack QMail. QMail crea e uccide molti file col passare del tempo ed era un server di posta molto occupato. Il fsck ha richiesto circa 36 ore. Non è che abbiamo risparmiato un sacco di prestazioni dall'accordo, ma alla fine suppongo che potresti sostenere che il filesystem fosse più sano. Ne è valsa davvero la pena il caos che ne è seguito? Non. In. Tutto.