Por que desligar minha máquina depois de uma `rm 'ruim salvou meus arquivos?

Situação clássica: Eu corri mal rme percebi imediatamente depois que havia removido os arquivos errados. (Nada crítico e eu tinha backups razoavelmente recentes, mas ainda irritantes.)

Sabendo que mais atividade em disco era minha inimiga, se eu quisesse recuperar os arquivos com extundeleteessas ferramentas, desliguei imediatamente a máquina fisicamente (por exemplo, com o botão liga / desliga, não com haltou com nenhum comando). Este era um laptop sem tarefas importantes em execução ou qualquer coisa aberta, por isso era uma operação aceitável. (A propósito, aprendi desde então que a primeira coisa a fazer em tal situação seria estimar primeiro se os arquivos ausentes ainda podem ser abertos por um processo https://unix.stackexchange.com/a/101247 - se estiverem, você deve recuperá-los dessa maneira, em vez de desligar a máquina.)

Ainda assim, depois que a máquina foi desligada, pensei por um tempo e decidi que os arquivos não valiam o investimento de tempo em inicializar um sistema ativo para análise forense adequada. Então, liguei a máquina novamente. E então descobri que meus arquivos ainda estavam no disco: rmeles não haviam sido propagados para o disco antes de eu desligar. Dancei um pouco e agradeci ao deus dos administradores de sistemas por Seu inesperado perdão.

Minha pergunta agora é entender como isso foi possível e qual é o atraso típico antes que um rmseja realmente propagado para o disco. Eu sei que as E / S do disco não são liberadas imediatamente, mas ficam na memória por algum tempo, mas pensei que o diário do disco garantiria rapidamente que as operações pendentes não fossem totalmente perdidas. https://unix.stackexchange.com/a/78766 parece sugerir um mecanismo separado para liberar páginas sujas e liberar operações do diário, mas não fornece detalhes suficientes sobre como o diário estaria envolvido em um rme o atraso esperado antes operações são liberadas.

Mais alguns detalhes: os dados estavam em uma partição ext4 dentro de um volume LUKS e, ao inicializar a máquina, vi o seguinte em 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)

mas não estou confiante de que esteja relacionado ao rm.

Outra pergunta seria se existe uma maneira de dizer ao kernel para não executar nenhuma das operações pendentes do disco (mas, digamos, despejá-las em algum lugar), em vez de desligar a máquina. (Obviamente, parece perigoso não executar as operações pendentes, mas é o que aconteceria ao desligar a máquina de qualquer maneira, e em alguns casos isso poderia salvá-lo.) Isso seria "mais limpo", é claro, e também interessante por exemplo, servidores remotos onde o desligamento físico não é uma opção fácil.

Parece que você tem uma idéia decente do que aconteceu.

Sim, porque você desligou o sistema antes que suas alterações fossem confirmadas no disco, elas estavam lá quando você reiniciava.

O sistema armazena em cache todas as gravações antes de liberá-las para o disco. Existem várias opções que controlam esse comportamento, todas localizadas em /proc/sys/vm/dirty_* ^{[ kernel doc ]} . A menos que uma descarga seja explicitamente executada por um aplicativo via fsync() ^{[ man 2 fsync ]} , os dados são confirmados quando tiver idade suficiente ou o cache de gravação for preenchido.
A definição de "dados", conforme usada acima, inclui modificações na entrada do diretório para excluir o arquivo.

Agora, quanto ao periódico, esse é um dos equívocos comuns sobre o objetivo do periódico. O objetivo de um diário não é garantir que as alterações sejam reproduzidas ou que os dados não sejam perdidos. O objetivo de um diário é impedir a corrupção do sistema de arquivos em si, não dos arquivos contidos nele. O diário simplesmente contém informações sobre as alterações que estão sendo feitas e não (normalmente) os dados completos da própria alteração. Os detalhes exatos dependem do sistema de arquivos e do modo de diário. Para ext3 / 4, consulte a dataopção de montagem em man 8 mount.

Para responder à sua pergunta complementar sobre se há uma maneira de impedir as gravações pendentes sem uma reinicialização:

Ao fazer uma leitura rápida do código fonte do kernel, parece que você pode usar o ucomando magic sysrq ^{([ wikipedia ], [ kernel doc ])} para executar uma operação emergencial de remontagem somente leitura. Parece que isso remontará imediatamente todos os volumes somente leitura sem uma operação de sincronização.

Para usar isso, basta pressionar Alt+ SysRq+ u.

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

commit = nrsec (*) Ext4 pode ser instruído a sincronizar todos os seus dados e metadados a cada segundo de 'nrsec'. O valor padrão é 5 segundos. Isso significa que, se você perder o poder, perderá os últimos 5 segundos de trabalho (o sistema de arquivos não será danificado, graças ao registro no diário). Esse valor padrão (ou qualquer valor baixo) prejudicará o desempenho, mas é bom para a segurança dos dados. Configurá-lo como 0 terá o mesmo efeito que deixá-lo no padrão (5 segundos). Configurá-lo para valores muito grandes melhorará o desempenho.

Veja também aqui como liberá-los: Como você esvazia os buffers e o cache em um sistema Linux?

Citado no link acima:

NOTA: limpe a memória de coisas desnecessárias (Kernerl 2.6.16 ou mais recente). Sempre execute a sincronização primeiro para liberar coisas úteis para o 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