ext [34] Opzione 'commit' e integrità del filesystem

4

Sto eseguendo un'installazione 10.10 abbastanza recente e vanigliata, costruita da zero circa un mese fa su un laptop Acer Aspire 5742. Uso openbox come gestore di finestre e non eseguo né gli stack desktop di KDE né quelli di Gnome. Non ho ancora capito come portare il sistema in stato di ibernazione quando il livello di carica della batteria è basso, quindi ricevo occasionali interruzioni di corrente.

Ho notato che quando il mio laptop passa all'alimentazione a batteria, le mie partizioni ext * vengono rimontate con l'opzione commit=600 .

Quando torno a AC, c'è un altro set di remounts con commit=0 .

Questo è evidente dalle voci in /var/log/syslog come

Mar 31 14:48:48 gatsby kernel: [414710.189306] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,commit=600
Mar 31 14:48:48 gatsby kernel: [414710.324137] EXT4-fs (dm-1): re-mounted. Opts: commit=600
Mar 31 14:48:48 gatsby kernel: [414710.749636] EXT4-fs (dm-2): re-mounted. Opts: commit=600
Mar 31 16:35:58 gatsby kernel: [421128.882072] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,commit=0
Mar 31 16:35:58 gatsby kernel: [421129.083283] EXT4-fs (dm-1): re-mounted. Opts: commit=0
Mar 31 16:35:59 gatsby kernel: [421129.724136] EXT4-fs (dm-2): re-mounted. Opts: commit=0

Il manuale mount spiega il significato dell'opzione count rispetto al filesystem ext3:

commit=nrsec
       Sync all data and metadata every nrsec seconds.
       The default value is 5 seconds. Zero means default.

Che cosa significa esattamente? Sembra implicare che le scritture possano essere memorizzate nella cache per un massimo di 10 minuti. Questo significa che potrebbe esserci il danneggiamento del filesystem o che alcune modifiche potrebbero non essere salvate se la batteria si esaurisce?

    
posta intuited 01.04.2011 - 04:54

1 risposta

2

Non dovrebbe causare il danneggiamento del file system (è un file system di journaling, dopotutto), ma potrebbe causare un lavoro perso.

Il motivo del comportamento è che la rotazione del disco consuma energia e, prima di eseguire un commit su giornale, è più probabile che si possano eseguire più scritture in una volta sola, con conseguente aumento degli spin-up e durata della batteria migliore.

Se ciò causa problemi, è possibile modificare l'intervallo di commit quando si utilizza la batteria. Le modifiche vengono eseguite dal pacchetto pm-utils , quindi crea un file sotto /etc/pm/config.d/ (il nome non ha importanza) con i seguenti contenuti:

JOURNAL_COMMIT_TIME_BAT=300

Quanto sopra imposta il timeout a 5 minuti. Puoi modificarlo se necessario.

    
risposta data James Henstridge 01.04.2011 - 08:29

Leggi altre domande sui tag