Quando è pericoloso fsck?

37

Recentemente ho visto il filesystem di root di una macchina in un datacenter remoto rimontato di sola lettura, a causa di problemi di coerenza.

Al riavvio, questo errore è stato mostrato:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

Dopo aver eseguito fsck come suggerito e aver accettato le correzioni manualmente con Y, gli errori sono stati corretti e il sistema ora va bene.

Ora, penso che sarebbe interessante se fsck fosse configurato per eseguire e riparare tutto automaticamente, poiché l'unica alternativa in alcuni casi (come questa) è andare di persona al datacenter remoto e collegare una console alla macchina interessata.

La mia domanda è: perché per impostazione predefinita fsck richiede un intervento manuale? Come e quando una correzione eseguita da tale programma non sarebbe sicura? Quali sono i casi in cui l'amministratore di sistema potrebbe voler lasciare da parte una correzione suggerita per qualche tempo (per eseguire alcune altre operazioni) o interromperla del tutto?

— scristalli
fonte

15

Se gli sviluppatori fossero sicuri al 100% che l'errore potesse essere corretto automaticamente, in primo luogo non sarebbe un errore.

— user253751,

42

fsckprovoca sicuramente più danni che benefici se l'hardware sottostante è in qualche modo danneggiato; CPU danneggiata, RAM danneggiata, disco rigido in via di esaurimento, controller del disco andato a male ... in quei casi è inevitabile una maggiore corruzione.

In caso di dubbio, è una buona idea semplicemente catturare un'immagine del disco danneggiato con dd_rescueo qualche altro strumento e quindi vedere se riesci a correggere correttamente quell'immagine. In questo modo hai ancora la configurazione originale disponibile.

— Janne Pikkarainen
fonte

4

Ho lavorato molto con hardware difettoso e sono d'accordo con questo. L'ultima cosa che voglio fare è fsck se si sospetta un hardware difettoso di qualsiasi tipo. Ho anche visto un evento a bassa potenza e il successivo recupero che è stato notevolmente ritardato da fsck automatico.

— Jorfus,

Per fare un esempio concreto: ho lavorato su una macchina con un controller del disco che "casualmente" (circa 1 volta in 10 ^ 5) trasformerebbe una lettura o una scrittura per bloccare XXXXXXYY su qualsiasi dispositivo su una scrittura per bloccare 000000YY sul primo dispositivo. Vale a dire, spesso esplodeva dati strutturati errati e non strutturati nel settore di avvio e varie strutture critiche del filesystem del disco di avvio. L'esecuzione di fsck in una situazione del genere (milioni di letture) può eliminare qualsiasi possibilità residua di recupero dei dati.

— Eric Towers,

2

1 su 10 ^ 5 è molto ... sono sempre 10 byte Mb.

— Nelson,

1

@Nelson: In un certo senso è ... L'unità contiene "trasferimenti a blocco singolo", non "byte". Quindi dieci scritture di blocchi errati per milione di blocchi (e i blocchi sono significativamente più grandi dei byte).

— Eric Towers,

21

Hai visto un esempio in cui ha fsckfunzionato, ma ho visto più di abbastanza file system danneggiati in cui non ha funzionato affatto. Se funzionasse in modo completamente automatico, potresti non avere alcuna possibilità di fare cose come un dddump del disco o qualcosa del genere che in molti casi sarebbe un'ottima idea da fare prima di tentare una riparazione.

Non è mai, mai una buona idea provare qualcosa del genere.

Oh, e i server moderni dovrebbero avere console remote o almeno sistemi di salvataggio indipendenti per recuperare da qualcosa del genere senza trascinare un rack KVM sul server.

— Sven
fonte

7

In realtà, ciò che non è una buona idea è quello di dire " mai, mai " così, quando non è vero. Caso d'uso in cui è una buona idea: le partizioni principali del server possono essere ricreate da zero piuttosto rapidamente, in caso di problemi. Ai dati realmente importanti si accede tramite un filesystem remoto, con un'adeguata ridondanza in atto per quei dati. Preferirei di gran lunga cogliere l'occasione fsck -p /e fsck -p /var, ecc., Lavorare bene e far funzionare il server senza intervento manuale, e rischierei la piccola possibilità, non zero, di una catastrofe maggiore per quelle partizioni che posso semplicemente ricreare se necessario .

— TOOGAM,

1

Se il sistema può essere facilmente reinstallato, lo faccio solo ...

— Sven

1

Ci vorrebbe più tempo. Le opzioni sono: A) Rischio di farlo automaticamente. B) Chiedi a qualcuno fsckdi preen e poi tutto funziona bene. Ci vogliono circa 2 minuti, se quello. Tempo di fermo fino a quando ciò accade. C) Chiedi a qualcuno di reinstallare il sistema operativo. Richiede più di 30 minuti. Stai scegliendo l'opzione C? Forse una differenza fondamentale è che ho avuto fsckun lavoro con una percentuale maggiore del tempo rispetto a quanto citi nella tua risposta. Il mio punto principale non era la progettazione del sistema (questo sistema economico-o non usa una console remota), ma solo che dire " mai, mai " era una frase troppo forte per essere accurati

— TOOGAM

Accettiamo di non essere d'accordo.

— Sven

0

Prima di tutto, devi capire che con i moderni filesystem (giornalizzati), un crash del sistema non corromperà il filesystem e non sarà richiesto fsck al momento dell'avvio.

Ext3, Ext4, ZFS, btrfs, xfs e tutti i moderni FS sono coerenti al 100% dopo un crash o un reset del sistema.

FS non giornalizzati come ext2 o vfat sono un grande NOGO per un rootfs di sistema.

Ora, se il tuo sistema richiede un fsck al momento dell'avvio, dovresti chiederti: qual è stato il motivo per questo in primo luogo?

In seguito dovresti esaminare i log del tuo kernel per scoprire quando e cosa è successo. Dovresti anche tornare indietro nel tempo nei log per trovare da quando è iniziato l'errore. Dovresti controllare i tuoi dischi con smartctl. Ecc ... Se hai bisogno di un fsck su un fs giornalizzato, è praticamente certo che il tuo hardware non funziona, supponendo che il fs non sia stato danneggiato da un amministratore (con strumenti a livello di blocco come dd) o da un bug.

Quindi è sciocco usare fsck per "risolvere" il problema senza indagare e correggere la causa principale (sostituendo / aggiornando l'hardware / firmware / software difettoso).

Fare un fsck, completare l'avvio ed essere felici è a dir poco ingenuo. Affermare "Ho avuto fsck work una percentuale maggiore delle volte rispetto a quello che citi" mi fa chiedermi cosa intendi con "fsck work". fsck potrebbe aver riportato i tuoi fs in uno stato coerente perdendo alcuni file e dati nel processo ... Hai confrontato con un backup? Molte persone perdono i file o ottengono la corruzione dei dati dei file senza accorgersene ...

— Francois Scheurer
fonte