Ho notato che XFS non implementa un fsck all'avvio del sistema e uno dei motivi propagandati in quel file system di journaling aiuta a garantire che il file system sia in uno stato coerente dopo un arresto impuro; sul mount successivo (ad es. dopo il riavvio) il diario viene riprodotto.
È ancora necessario un fsck dopo uno spegnimento impuro e perché?
Risposte:
Sto rispondendo a questo nel contesto generale di "filesystem con journaling".
Penso che se hai fatto un certo numero di "shutdown sporchi" (dal tirando il cavo di alimentazione o qualcosa ) prima o poi ci si arriva a uno stato filesystem che richiederebbe fscko l'equivalente morale di fsck, xfs_repair. Il ext4fileystsm sul mio laptop per la maggior parte riproduce semplicemente il diario ad ogni riavvio, compresi gli arresti puliti, ma ogni tanto fa un full-on fsck.
Ma chiediti cosa "riesegue il diario". La riproduzione di un giornale assicura solo che i blocchi del disco del resto del file system corrispondano all'ordine richiesto dalle voci del giornale. La riproduzione di un diario equivale a un piccolo fscko a parti di un full on fsck.
Penso che ci sia un po 'di gioco verbale in corso: la riproduzione di un diario fa parte di ciò che fsckfa tradizionale , ed xfs_repairè esattamente lo stesso tipo di programma che e2fs.fsck(o qualsiasi altro filesystem fsck) è. Le persone XFS hanno appena creduto o la loro esperienza li ha portati a non funzionare xfs_repairad ogni avvio, solo a riprodurre il diario.
fscknon è "pedante". Ho convertito una ext3 LVMpartizione in ext4e ho iniziato a ricevere errori "ext4_mb_generate_buddy" a causa, a quanto ho capito, di un bug nel ext4codice che causava una mancata corrispondenza nelle copie su disco e in memoria della bitmap su partizioni "LVM" convertite. Per quanto ne so fsck, non si è verificata alcuna corruzione. La soluzione era o disattivare l' UNINIT_BGopzione o spostare i dati e reinizializzare la partizione come ext4; Ho seguito quest'ultimo corso. Ma penso ancora che aspettare qualche minuto fscknon valga la pena perdere dati!
aiutare a garantire che il file system sia in uno stato coerente dopo un arresto impuro
La prima cosa da notare è che XFS, reiser e la maggior parte delle configurazioni di ext implementano solo il journaling dei metadati, il che significa evitare fsck. Il journal non viene sempre riprodotto all'avvio: potrebbe essere scartato se incompleto.
Esistono sistemi che supportano il journaling completo dei dati, ma in pratica il livello di sicurezza che questi offrono rispetto al solo journaling dei metadati è molto piccolo negli scenari del mondo reale.
Quindi uno "stato incoerente" e i problemi risolti da fsck sono discrepanze tra i metadati e i file stessi. Per evitare ciò, il sistema operativo scrive le modifiche ai metadati proposte sul journal, quindi scrive i dati effettivi sul disco, quindi applica le modifiche ai metadati replicate nel journal sul disco. L'unico problema è che il controller del disco eseguirà il buffer e riordinerà potenzialmente le richieste. Per evitare ciò, la maggior parte dei filesystem di journaling implementa barriere: separano ogni operazione e attendono che il disco riconosca che ha completato l'operazione. Ma molti dischi moderni in realtà riconoscono il completamento delle scritture prima che i dati vengano impegnati. Quindi, le cose possono diventare confuse.
È ancora necessario un fsck dopo un arresto impuro e perché
La maggior parte dei filesystem mantiene un conteggio dei mount - una volta raggiunto questo conteggio, al successivo tentativo di montare il disco verrà attivato un fsck completo. Il motivo è che i dati del disco possono essere danneggiati anche quando non vengono scritti in modo esplicito, anche senza bug nel software. Il commento di psusi sopra è sbagliato.
hdparm -W), il disco non completa le richieste di scrittura finché non si trova sul supporto. Perché pensi che questa opzione esista? Le barriere impediscono il riordino quando vengono emesse più richieste. Senza barriere, la fs semplicemente non emette più richieste fino a quando le precedenti non sono state completate, mantenendo così l'ordinamento senza barriere ... a condizione che la cache di scrittura su disco non sia abilitata. Lo scopo delle barriere è consentire all'utente di abilitare la cache di scrittura, senza corrompere la fs in caso di crash.
sync. Fammi riprovare. La procedura per scrivere sul disco senza barriere è scrivere sul journal sync, quindi svuotare eventuali cache di scrittura, quindi scrivere i dati reali. Questo assicura che il diario possa sempre essere usato per recuperare gli fs dopo un crash, ma la sincronizzazione rallenta le cose e metà vanifica lo scopo della cache di scrittura. Pertanto, sono state aggiunte barriere per sostituire meglio synce, con il supporto del disco appropriato, possono recuperare in sicurezza gran parte delle prestazioni che la sincronizzazione porta via.
Non è necessario salvare un filesystem di journaling semplicemente a causa di un arresto impuro.
L' intero motivo per sopportare la penalità delle prestazioni di runtime del journaling dei metadati è quello di garantire che il filesystem possa essere reso nuovamente coerente al 100% riproducendo automaticamente il registro dei metadati sul mount successivo, se il filesystem non è stato chiaramente smontato.
L'unico ruolo di fsck è assicurare la coerenza dei metadati, quindi è ridondante eseguire fsck semplicemente perché il filesystem non è stato correttamente smontato.
Un filesystem journaling può essere danneggiato per altri motivi - guasti hardware, bug dei driver, errori di amministrazione, ecc. - quindi gli strumenti fsck sono sicuramente necessari. Non c'è motivo di invocarli solo a causa di un arresto impuro.