<Precedenti | Contenuti | Succ.>
Test e riparazione di file system
Nella nostra precedente discussione sull' /etc/fstab file, abbiamo visto alcune cifre misteriose alla fine di ogni riga. Ogni volta che il sistema si avvia, controlla regolarmente l'integrità dei file system prima di montarli. Questo viene fatto da fsck programma (abbreviazione di "controllo del file system"). L'ultimo numero in ogni fstab La voce specifica l'ordine in cui i dispositivi devono essere controllati. Nel nostro esempio precedente, vediamo che il file system radice viene controllato per primo, seguito dal casa e stivale file system. I dispositivi con uno zero come ultima cifra non vengono controllati di routine.
Oltre a controllare l'integrità dei file system, fsck può anche riparare file system corrotti con vari gradi di successo, a seconda dell'entità del danno. Sui file system di tipo Unix, le parti recuperate dei file vengono posizionate nel perso + trovato directory, situata nella radice di ciascun file system.
Per controllare la nostra unità flash (che dovrebbe essere smontata per prima), potremmo fare quanto segue:
[io@linuxbox~]$ sudo fsck / dev / sdb1
fsck 1.40.8 (13-mar-2016)
e2fsck 1.40.8 (13-mar-2016)
/dev/sdb1: pulito, 11/3904 file, 1661/15608 blocchi
[io@linuxbox~]$ sudo fsck / dev / sdb1
fsck 1.40.8 (13-mar-2016)
e2fsck 1.40.8 (13-mar-2016)
/dev/sdb1: pulito, 11/3904 file, 1661/15608 blocchi
Nella mia esperienza, il danneggiamento del file system è piuttosto raro, a meno che non ci sia un problema hardware, come un disco rigido difettoso. Nella maggior parte dei sistemi, il danneggiamento del file system rilevato all'avvio causerà l'arresto del sistema e richiederà di eseguire fsck prima di continuare
Che diavolo?
Nella cultura Unix, la parola "fsck" viene spesso usata al posto di una parola popolare con cui condivide tre lettere. Questo è particolarmente appropriato, dato che probabilmente pronuncerete la parola sopra menzionata se vi trovate in una situazione in cui siete costretti a eseguire fsck.