Quale opzione di montaggio utilizzare per il file system ext3 per ridurre al minimo la perdita o la corruzione dei dati?


15

Ho un setup incorporato usando un initramfs per il file system di root ma usando una partizione ext3 personalizzata montata su un'unità IDE flash compatta. Poiché l'integrità dei dati di fronte alla perdita di potenza è il fattore più importante nell'intera installazione, ho utilizzato le seguenti opzioni per montare (di seguito è la voce dal mio /etc/fstabfile

<file system> <mount pt> <type> <options>                         <dump><pass>
/dev/sda2     /data      ext3   auto,exec,relatime,sync,barrier=1 0     2

Sono arrivato a queste opzioni leggendo su Internet. Ciò di cui sono preoccupato è che il contenuto di /proc/mountsdare quanto segue:

/dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl,
barrier=1,data=writeback 0 0

Da quello che ho capito leggendo è che voglio usare l' data=journalopzione per il mio mount in quanto offre la migliore protezione contro la corruzione dei dati. Tuttavia, dalla pagina man per specifiche opzioni ext3 per mountesso dice quanto segue sull'opzione writeback:

L'ordinamento dei dati non viene conservato: i dati possono essere scritti nel filesystem principale dopo che i relativi metadati sono stati inseriti nel journal.
Si dice che questa sia l'opzione con la massima produttività. Garantisce l'integrità interna del filesystem , tuttavia può consentire ai vecchi dati di apparire nei file dopo un arresto anomalo e il ripristino del journal.

Sono molto confuso su questo - la pagina man sembra suggerire che per l'integrità del file system voglio specificare l' data=writebackopzione mountma la maggior parte degli altri riferimenti che ho trovato (inclusi alcuni libri pubblicati su Linux embedded) suggeriscono che dovrei usare data=journal. Quale sarebbe l'approccio migliore per me da usare? La velocità di scrittura non è affatto un problema, tuttavia l'integrità dei dati.


1
Fornisce alcune indicazioni su data = journal . Sarei propenso a usarlo su qualsiasi altra cosa poiché RH supporta solo quel tipo di ordinazione.
slm

2
@sim in realtà dice data=ordered: p
sourcejedi

Risposte:


7

Non lasciarti ingannare dal fatto che writebackmenziona solo internal filesystem integrity.
Con ext3, se usate journal, orderedo writeback, metadati del file system è sempre sopportato e che mezzi integrità del file system interno.

Le modalità dati offrono un modo per controllare il modo in cui i dati ordinari vengono scritti nel file system.
In writebackmodalità, le modifiche ai metadati vengono prima registrate nel journal e viene scritto un blocco commit. Dopo l'aggiornamento del journal, è possibile procedere alla scrittura di metadati e dati. data=writeback può essere un grave rischio per la sicurezza: se il sistema si arresta in modo anomalo durante l'aggiunta a un file, dopo che i metadati sono stati impegnati (e allocati blocchi di dati aggiuntivi), ma prima che i dati siano stati scritti (blocchi di dati sovrascritti con nuovi dati), quindi dopo il journal il recupero di quel file può contenere blocchi pieni di dati da file precedentemente eliminati - da qualsiasi utente 1 .

Quindi, se l'integrità dei dati è la tua principale preoccupazione e la velocità non è importante, data=journalè la strada da percorrere.


4

Come hai già notato, il punto principale è che non puoi impedire al tuo filesystem di tutti i tipi di crash.

Cosa puoi fare:

  1. Per quanto riguarda il software, puoi usare fdatawrites dopo ogni operazione importante (vedi questo post del 2003 di Theodore T'so, uno dei principali sviluppatori del kernel FS Linux. È ancora vero. C'è anche questo su una perdita di dati importante nascosta nelle versioni precedenti di ext4)
  2. Riduci l'intervallo di commit a 1 secondo ( commit = 1 ) (vedi questo articolo da LWN, parla di ext4 ma contiene informazioni davvero utili su ext3). NB: Non dovrebbe essere necessario, con la sincronizzazione .
  3. Come ha detto RHEL doc indicato da sim, usa * data_err = abort * e data = ordinato
  4. noatime ridurrà le operazioni inutili sul filesystem
  5. Come hai già notato, barrier = 1 è un buon modo per ridurre al minimo la perdita di dati (vedi questo post )
  6. E la sincronizzazione è anche, ovviamente, una delle opzioni "Non voglio perdere i miei dati".

Alla fine, le opzioni di montaggio paranoico possono apparire così:

auto,exec,relatime,sync,barrier=1,commit=1,data=ordered,data_err=abort,noatime,

E puoi anche garantire l'integrità dei dati con un fsck automatico ad ogni avvio.


2

Prova a cambiare quale parte della pagina man enfatizzi:

rispondere

L'ordinamento dei dati non viene conservato : i dati possono essere scritti nel filesystem principale dopo che i relativi metadati sono stati inseriti nel journal. Si dice che questa sia l'opzione con la massima produttività. Garantisce l'integrità interna del filesystem, tuttavia può consentire ai vecchi dati di apparire nei file dopo un arresto anomalo e il ripristino del journal.

Come ha sottolineato don_crissti, le altre modalità non hanno "comunque".

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.