Sto ponendo questa domanda per conto di un altro utente che ha sollevato il problema nella chat room di Ubuntu.
I filesystem journaling garantiscono che non si verifichino danni in caso di interruzione dell'alimentazione?
Se questa risposta dipende dal filesystem, indica quali proteggono dalla corruzione e quali no.
Risposte:
Non ci sono garanzie Un file system di journaling è più resistente ed è meno soggetto alla corruzione, ma non immune.
Tutto un diario è un elenco di operazioni che sono state recentemente eseguite sul file system. La parte cruciale è che la registrazione prima nota viene effettuata prima delle operazioni. La maggior parte delle operazioni prevede più passaggi. L'eliminazione di un file, ad esempio, potrebbe comportare l'eliminazione della voce del file nel sommario del file system e quindi contrassegnare i settori sull'unità come liberi. Se succede qualcosa tra i due passaggi, un file system con journal può dirlo immediatamente ed eseguire la pulizia necessaria per mantenere tutto coerente. Questo non è il caso di un file system senza journal che deve cercare l'intero contenuto del volume per trovare errori.
Mentre questo journaling è molto meno incline alla corruzione rispetto al non journaling, la corruzione può ancora verificarsi. Ad esempio, se il disco rigido non funziona in modo meccanico o se le scritture sul giornale stesso non funzionano o vengono interrotte.
La premessa di base del journaling è che la scrittura di una registrazione prima nota è in genere molto più rapida rispetto alla transazione effettiva descritta. Quindi, il periodo tra il sistema operativo che ordina una scrittura (journal) e il disco rigido che lo compie è molto più breve rispetto a una normale scrittura: una finestra più stretta in cui le cose vanno male, ma c'è ancora una finestra.
No.
Il tipo di journaling più comune, chiamato journaling dei metadati, protegge solo l'integrità del file system, non dei dati. Ciò include xfse ext3/ ext4nella data=orderedmodalità predefinita .
Se un file system senza journaling subisce un arresto anomalo, verrà verificato utilizzando fsckall'avvio successivo. fsckesegue la scansione di tutti gli inode sul file system, cercando i blocchi contrassegnati come utilizzati ma non raggiungibili (ovvero senza nome file) e li contrassegna come inutilizzati. Fare questo richiede molto tempo.
Con un file system di journaling dei metadati, invece di eseguirne uno fsck, sa quali blocchi era nel mezzo del cambiamento, quindi può contrassegnarli come liberi senza cercarli nell'intera partizione.
Esiste un tipo di journaling meno comune, chiamato journaling dei dati, che è ciò che ext3fa se lo si monta con l' data=journalopzione.
Tenta di proteggere tutti i tuoi dati scrivendo non solo un elenco di operazioni logiche, ma anche l'intero contenuto di ogni scrittura sul diario. Ma poiché sta scrivendo i tuoi dati due volte, può essere molto più lento.
Come altri hanno sottolineato, anche questa non è una garanzia, perché il disco rigido avrebbe potuto dire al sistema operativo che aveva archiviato i dati, quando in realtà era ancora nella cache del disco rigido.
Per ulteriori informazioni, dai un'occhiata all'articolo Wikipedia File System Journaling e alla sezione Modalità dati della documentazione ext4 .
data=journalcome caratteristica non ha alcun senso?
Un filesystem non può garantire la coerenza del suo filesystem se si verifica un'interruzione di corrente, perché non sa cosa farà l'hardware.
Se un disco rigido esegue il buffering dei dati per la scrittura ma comunica al sistema operativo che ha scritto i dati e non supporta le barriere di scrittura appropriate, possono verificarsi scritture fuori servizio in cui una scrittura precedente non ha colpito il piatto, ma una successiva ha. Vedi questa risposta predefinita del server per maggiori dettagli.
Inoltre, la posizione della testa su un HDD magnetico è controllata con elettromagneti. Se il potere si interrompe nel mezzo di una scrittura, è possibile che alcuni dati continuino a essere scritti mentre le teste si muovono, corrompendo i dati su blocchi che il filesystem non ha mai pensato di essere scritto.
ZFS, che è vicino ma non esattamente un filesystem journaling, garantisce in modo progettuale contro la corruzione dopo un'interruzione di corrente.
Non importa se una scrittura in corso viene interrotta nel mezzo in quanto in tal caso, il suo checksum sarà sicuramente errato, quindi il blocco verrà ignorato. Poiché il file system viene copiato in scrittura, i dati corretti (o metadati) precedenti sono ancora presenti sul disco e verranno invece utilizzati.
La risposta è nella maggior parte dei casi no: