Per fsck o non fsck dopo 180 giorni

Di default dopo 180 giorni o un certo numero di montaggi, la maggior parte dei filesystem Linux forza un controllo del file system (fsck). Naturalmente questo può essere disattivato usando, ad esempio, tune2fs -c 0 -i 0 su ext2 o ext3.

Su filesystem di piccole dimensioni, questo controllo è semplicemente un inconveniente. Tuttavia, dati i filesystem più grandi, il completamento di questo controllo può richiedere ore e ore. Quando i tuoi utenti dipendono da questo filesystem per la loro produttività, diciamo che sta servendo le loro home directory tramite NFS, disabiliteresti il ​​controllo del file system pianificato?

Faccio questa domanda perché attualmente sono le 2:15 e sto aspettando un lungo fsck per completare (ext3)!

Il tempo predefinito di 180 giorni fsck è una soluzione alternativa al difetto di progettazione che ext3 non supporta un controllo di coerenza online. La vera soluzione è trovare un filesystem che supporti questo. Non so se ci sia un filesystem maturo. È una vera tragedia. Forse btrfs ci salverà un giorno.

Ho risposto al problema dei tempi di inattività di un'ora di sorpresa di fsck eseguendo riavvii programmati con un fsck completo come parte della manutenzione standard. È meglio che imbattersi in una piccola corruzione durante le ore di produzione e trasformarla in una vera e propria interruzione.

Una grande parte del problema è che ext3 ha un fsck irragionevolmente lento. Sebbene xfs abbia un fsck molto più veloce, usa troppa memoria per le distribuzioni per incoraggiare xfs di default 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ò può rendere più facile programmare 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 il fatto che probabilmente ci sono poche persone che usano xfs sul kernel che stai eseguendo.

La mia comprensione è che il progetto ext4 ha l'obiettivo di migliorare almeno un po 'le prestazioni di fsck.

Direi che questo è solo un altro motivo per cui i server di produzione non dovrebbero essere eseguiti 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 fisico fatto ogni X giorni, pronti a subentrare.

A parte 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 non di backup di un client, potresti voler pianificare in anticipo la prossima volta :-)

Dipende .. Ad esempio abbiamo avuto un server inattivo per la manutenzione ordinaria che eseguiva uno stack QMail. QMail crea e uccide molti file col passare del tempo ed era un server di posta molto impegnato. La fsck impiegò circa 36 ore. Non è come se avessimo risparmiato un sacco di prestazioni fuori dall'accordo, ma alla fine suppongo che si possa sostenere che il filesystem fosse più sano. Ne è valsa davvero la pena il caos che ne è derivato? Non. A. Tutti.

XFS è interessante. È un FS sempre coerente. Non ha bisogno di fsck. Non causerà tempi di inattività a causa di fsck.

Ma ha un altro problema. È necessario un controller RAID con supporto per la gestione dei blocchi danneggiati dell'HDD.

XFS non ha la funzione di inserire nella blacklist i blocchi danneggiati quando il sistema operativo inizia a conoscere blocchi danneggiati e l'elenco di blocchi danneggiati dell'hardware dell'HDD è pieno.

ext2 / 3/4, fat, ntfs, ecc (test offline) sono in grado di inserire nella blacklist i blocchi danneggiati ma non XFS.

Quindi, per installazioni non aziendali, XFS probabilmente non va bene. Sto usando XFS con il software raid1 di Linux per le partizioni di backup in cui il contenuto è un sacco di piccoli file con non molto cambiamento nel tempo.