2015-07-10 8 views
10

Il filesystem ext4 può rilevare la corruzione dei dati dei contenuti dei file? Se sì, è abilitato per impostazione predefinita e come posso verificare la presenza di dati corrotti?Può est4 rilevare il contenuto del file danneggiato?

Ho letto che ext4 mantiene i checksum per i metadati di file e il suo diario, ma non sono riuscito a trovare alcuna informazione sui checksum per il contenuto del file attuale.

Per chiarezza: voglio sapere se un file è cambiato dall'ultima operazione di scrittura.

risposta

3

"Il file system ext4 può rilevare la corruzione dei dati dei contenuti dei file?" Non nel senso che ti aspetti. Esegue l'inserimento nel journal, creando una copia booleana {prima vs dopo} per garantire il completamento.

Un CRC/checksum è un test per la modifica da uno stato noto e sebbene il CRC o il checksum non possa essere paragonato all'originale, ciò non implica che il file sia "corrotto" (ovvero non valido) - - solo dice che è stato cambiato. A rigor di termini, una forma di "corruzione" sarebbe quella di alterare il "numero magico" all'inizio di un file, come cambiare% PDF in% xYz - - che renderebbe il contenuto inutilizzabile per qualsiasi programma.

"... per sapere se un file è cambiato dall'ultima operazione di scrittura". I sistemi che tracciano mtime() lo faranno in modo uniforme, quindi ogni scrittura modificherà mtime() rendendo impossibile la richiesta.

L'unico modo in cui mtime() non riflette l'ultima scrittura io sarebbe la degredation dei media.

+1

Grazie. Per essere sicuro di averti compreso: diciamo che scrivo un file, poi spengo il mio computer e per qualche motivo il contenuto del file cambia (a causa della degredazione dei media, degli effetti ambientali o qualcosa del genere). Dopo l'avvio di nuovo, non c'è modo di rilevare la modifica? –

+3

@jobeard ext4 non calcola né memorizza i CRC sui blocchi di dati. L'OP sta chiedendo informazioni sulla corruzione silenziosa dei dati, sembra che tu stia descrivendo il danneggiamento volontario dei dati (ad es .:% xYz). Questa è una storia diversa. Il degrado dei media è una causa comune di danneggiamento dei dati silenziosi, ma non l'unico che può verificarsi. La porzione di dati di un file può essere sovrascritta accidentalmente o intenzionalmente senza che il file mtime sia interessato (accesso raw) o dopo il reset di mtime in seguito. – jlliagre

+0

Non ho detto che ext4 ha fatto crc, ma ho sottolineato che il CRC era un mezzo per rilevare l'alterazione, ma l'alterazione non era la stessa cosa di "corruzione". Ha anche sottolineato che la "corruzione" ha diversi sapori e l'alterazione il numero magico sarebbe un esempio di corruzione che rende il file "non valido". Per quanto riguarda "intenzionalmente sovrascritto", questo è del tutto fuori dalla questione IMO, anche se è vero. – jobeard

10

No, ext4 non rileva e non è in grado di rilevare la corruzione del contenuto del file.

I file system ben conosciuti che implementano il rilevamento di danneggiamento dei dati silenziosi e quindi in grado di correggerli quando è disponibile una ridondanza sufficiente sono ZFS e btrfs.

Lo fanno calcolando e memorizzando un CRC per ogni blocco di dati scritto e controllando il CRC o ogni blocco di dati letto. Se il CRC non corrisponde ai dati, quest'ultimo non viene fornito al chiamante e RAID consente invece di utilizzare un blocco alternativo oppure viene segnalato un errore I/O.

Il processo di lettura non riceverà mai dati danneggiati, o è corretto o la lettura non riesce.

+0

Raid-2 ha fatto questo, ma ora è obsoleto, ZFS è implementato in Sunmicro Solaris e BTRFS è una scelta in Linux (vedere https://en.wikipedia.org/wiki/Btrfs) – jobeard

+0

@jobeard Solaris ZFS è sviluppato da Oracle adesso. C'è anche un fork ZFS da cui sono implementate implementazioni ZFS per derivati ​​OpenSolaris (illumos), FreeBSD, Linux e OS X. – jlliagre

+0

Il controllo CRC dei metadati è l'unica cosa implementata ora. –

Problemi correlati