Quanto tempo è possibile memorizzare nella cache le scritture del file system con ext4?

Qualche tempo fa, si è discusso di ext4 che potenzialmente lasciava file vuoti dopo uno smontaggio impuro, riassunto abbastanza bene in questo articolo . Fondamentalmente, a causa dell'allocazione ritardata, le scritture possono essere conservate nella cache di scrittura per un tempo molto più lungo dell'intervallo di commit predefinito del journal ext (5 secondi).

I problemi sembrano essere stati risolti in una patch che forza l'allocazione dei blocchi in determinate situazioni, forzando i dati su disco dopo al massimo 5 secondi per impostazione predefinita.

Mi chiedo cosa succede quando un'applicazione sovrascrive parti esistenti di un file, senza troncare o aggiungere il file stesso. Sarà forzato anche su disco entro 5 secondi?

Sembra una situazione diversa rispetto all'aggiunta a un file: quando si aggiunge, la dimensione del file cambia, che è una modifica dei metadati; pertanto, entro 5 secondi sarà necessario un commit del journal e, a causa dei dati = ordinati, i dati dovranno essere scritti prima a causa di problemi di sicurezza (altrimenti parti del file cancellati di altri utenti potrebbero essere mostrate al proprietario dell'aggiunta file).

Quando si sovrascrive solo i dati del file, non vi è alcun motivo per cui la scrittura dei dati debba avvenire prima del commit del journal dei metadati, poiché i vecchi dati appartengono allo stesso utente di quello nuovo. Quindi la scrittura avviene prima del commit o può essere ritardata più a lungo dell'intervallo di commit del journal? In tal caso, per quanto tempo?

Aggiornamento: so che tutto ciò è irrilevante quando si fa la cosa giusta, cioè usando fsync (). (Questo è stato il motivo principale di tutte le discussioni su ext4 e la perdita di dati - il problema riguardava solo le applicazioni non fsync () ing, o non nei momenti giusti.) Non sto scrivendo la mia applicazione, chiedo perché non so se tutte le mie applicazioni fanno la cosa giusta, e voglio sapere un lasso di tempo approssimativo per tali scritture "pericolose". Il motivo per cui mi viene chiesto è che il mio driver grafico causi regolarmente il panico del kernel e voglio sapere se devo preoccuparmi di più degli ultimi 5 secondi di scrittura dei dati.

È possibile impostare l'intervallo di commit su un valore personalizzato che, credo, può essere alto quanto un numero intero senza segno a 32 bit di secondi; quindi circa 4 miliardi di secondi, o 136 anni. Questo è disponibile tramite l' commitopzione mount, che puoi applicare come segue (questo è solo un esempio; puoi anche impostarlo in fstab):

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

L'intervallo di commit non si basa su alcun tipo di condizione, ad esempio se i dati vengono aggiunti o sovrascritti su dati esistenti o altro. L' commitopzione mount (che per impostazione predefinita è 5 secondi se non fornisci affatto l'opzione mount) equivale a fare qualcosa del genere in una shell bash:

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

Non confondere data=orderede questo intervallo di sincronizzazione del filesystem globale ("intervallo di commit" è forse un termine meno significativo per quelli di noi che comprendono la funzionalità del programma da riga di comando sync, nel qual caso potrebbe essere meglio chiamato "intervallo di sincronizzazione"). data=orderedriguarda l' ordine in cui i dati e i metadati vengono aggiornati (dove data=writebackè "meno sicuro / più veloce" ed data=journalè "più sicuro / più lento"). commit=12345678riguarda la frequenza con cui il driver del filesystem stesso forza una sincronizzazione COMPLETA di TUTTI i dati / journal / metadati sporchi su qualunque supporto fisico. E puoi sicuramente impostarlo su 136 anni se vuoi, e montare con data=writeback,nobhe programmi che non chiamano fsync()o sync()avranno pagine sporche in RAM per ...

Aggiornamento: in base al contesto nella modifica della domanda, direi che dovresti eseguire il tuo filesystem con le opzioni di mount data=journal,commit=1o anche con l' syncopzione di mount, fino a quando non sarai in grado di risolvere i panici del kernel del driver grafico. Ciò manterrà la massima integrità dei dati ma a scapito delle prestazioni. In particolare, ti consigliamo di farlo se scrivi spesso su disco dati che non puoi permetterti di perdere, e questo è doppiamente importante se non ti fidi delle app che stai utilizzando per impiegare in modo fsync()appropriato.

Fonte: qui ed esperienza personale

Qualunque sia la risposta alla tua domanda, non importa.

Il comportamento esposto garantito del filesystem ext4 è che "i dati saranno sul disco dopo una chiamata sync/ riuscita fsync". Pertanto, se si dispone di un'applicazione che ti fa porre questa domanda, è necessario inserire chiamate di sincronizzazione nei punti critici in cui è necessario garantire l'integrità dei dati. Se sei un utente preoccupato per lo stesso problema, puoi chiamare l' syncutilità della riga di comando prima di eseguire qualsiasi comportamento pericoloso che potrebbe causare un arresto impuro.