Perché lo spegnimento del mio computer dopo un brutto `rm` ha salvato i miei file?

Situazione classica: ho corso male rme mi sono reso conto subito dopo di aver rimosso i file sbagliati. (Niente di critico e ho avuto backup abbastanza recenti, ma comunque fastidiosi.)

Sapendo che un'ulteriore attività del disco era il mio nemico se volevo recuperare i file con extundeleteo tali strumenti, ho immediatamente spento la macchina fisicamente (cioè con il pulsante di accensione, non con halto qualsiasi comando simile). Era un laptop senza compiti importanti in esecuzione o con qualcosa di aperto, quindi era un'operazione accettabile. (A proposito, ho imparato da allora che la prima cosa da fare in una situazione del genere sarebbe stimare prima se i file mancanti potrebbero essere ancora aperti da un processo https://unix.stackexchange.com/a/101247 - se lo sono, è necessario ripristinarli in questo modo anziché spegnere la macchina.)

Tuttavia, una volta che la macchina è stata spenta, ho pensato per un po 'e ho deciso che i file non valevano il tempo impiegato per l'avvio di un sistema live per una corretta analisi forense. Quindi ho riacceso la macchina. E poi ho scoperto che i miei file erano ancora su disco: rmnon erano stati propagati su disco prima di averlo spento. Ho fatto una piccola danza e ho ringraziato il dio degli amministratori di sistema per il suo inatteso perdono.

La mia domanda ora è capire come ciò sia stato possibile e quale sia il ritardo tipico prima che un oggetto rmvenga propagato su disco. So che l'IO del disco non viene scaricato immediatamente ma che rimane in memoria per un po 'di tempo, ma ho pensato che il journal del disco si sarebbe assicurato rapidamente che le operazioni in sospeso non venissero completamente perse. https://unix.stackexchange.com/a/78766 sembra suggerire un meccanismo separato per svuotare le pagine sporche e svuotare le operazioni del giornale, ma non fornisce dettagli sufficienti su come il giornale sarebbe coinvolto per un rme il ritardo previsto prima le operazioni vengono scaricate.

Qualche dettaglio in più: i dati erano in una partizione ext4 all'interno di un volume LUKS, e all'avvio del backup della macchina ho visto quanto segue in syslog:

Sep 24 10:24:58 gamma kernel: [   11.457007] EXT4-fs (dm-0): 1 orphan inode deleted
Sep 24 10:24:58 gamma kernel: [   11.458393] EXT4-fs (dm-0): recovery complete
Sep 24 10:24:58 gamma kernel: [   11.482475] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

ma non sono sicuro che sia legato al rm.

Un'altra domanda sarebbe se c'è un modo per dire al kernel di non eseguire nessuna delle operazioni su disco in sospeso (ma piuttosto, diciamo, scaricarle da qualche parte), piuttosto che spegnere la macchina. (Certo, sembra pericoloso non eseguire le operazioni in sospeso, ma questo è ciò che accadrebbe quando si spegne comunque la macchina, e in alcuni casi potrebbe salvarti.) Sarebbe "più pulito", ovviamente, e anche interessante ad es. server remoti in cui il powerdown fisico non è un'opzione facile.

Sembra che tu abbia una buona comprensione di quello che è successo.

Sì, poiché hai spento il sistema prima che le tue modifiche fossero impegnate su disco, erano presenti al momento del riavvio.

Il sistema memorizza nella cache tutte le scritture prima di scaricarle sul disco. Esistono diverse opzioni che controllano questo comportamento, tutte situate su /proc/sys/vm/dirty_* ^{[ kernel doc ]} . A meno che un flush non sia esplicitamente eseguito da un'applicazione tramite fsync() ^{[ man 2 fsync ]} , i dati vengono ^salvati quando sono abbastanza vecchi o la cache di scrittura viene riempita.
La definizione di "dati" utilizzata in precedenza include la modifica della voce della directory per eliminare il file.

Ora, per quanto riguarda il diario, questo è uno dei malintesi comuni a cosa serve il diario. Lo scopo di un diario non è garantire la riproduzione delle modifiche o la perdita di dati. Lo scopo di un giornale è prevenire la corruzione del file system stesso, non dei file in esso contenuti. Il diario contiene semplicemente informazioni sulle modifiche apportate e non (in genere) i dati completi della modifica stessa. I dettagli esatti dipendono dal filesystem e dalla modalità journal. Per ext3 / 4, vedere l' dataopzione mount in man 8 mount.

Per rispondere alla domanda supplementare se esiste un modo per impedire le scritture in sospeso senza riavvio:

Dal fare una rapida lettura del codice sorgente del kernel, sembra che tu possa usare il ucomando magic sysrq ^{([ wikipedia ], [ kernel doc ])} per eseguire un'operazione di sola lettura di rimontaggio di emergenza. Sembra che questo rimonterà immediatamente tutti i volumi di sola lettura senza un'operazione di sincronizzazione.

Per usarlo, premi semplicemente Alt+ SysRq+ u.

Da: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

commit = nrsec (*) A Ext4 si può dire di sincronizzare tutti i suoi dati e metadati ogni 'nrsec' secondi. Il valore predefinito è 5 secondi. Ciò significa che se perdi il tuo potere, perderai tanto quanto gli ultimi 5 secondi di lavoro (il tuo filesystem non verrà danneggiato, grazie al journaling). Questo valore predefinito (o qualsiasi valore basso) comprometterà le prestazioni, ma è buono per la sicurezza dei dati. Impostandolo su 0 avrà lo stesso effetto di lasciarlo sul valore predefinito (5 secondi). Impostarlo su valori molto grandi migliorerà le prestazioni.

Vedi anche qui come svuotarli : come svuotare i buffer e la cache su un sistema Linux?

Citato dal link sopra:

NOTA: ripulisci la memoria di cose inutili (Kernerl 2.6.16 o più recenti). Assicurati sempre di eseguire prima la sincronizzazione per scaricare le cose utili sul disco !!!

To free pagecache:

$ echo 1 > /proc/sys/vm/drop_caches

To free dentries and inodes:

$ echo 2 > /proc/sys/vm/drop_caches

To free pagecache, dentries and inodes:

$ echo 3 > /proc/sys/vm/drop_caches