Por que desligar minha máquina após um mau 'rm' salvou meus arquivos?

Question

Situação clássica: Eu corri um rm ruim e percebi imediatamente que eu havia removido os arquivos errados. (Nada crítico e eu tive backups razoavelmente recentes, mas ainda irritante.)

Sabendo que mais atividade do disco era meu inimigo se eu quisesse recuperar os arquivos com extundelete ou tais ferramentas, eu desliguei a máquina imediatamente fisicamente (ou seja, com o botão liga / desliga, não com halt ou qualquer comando desse tipo ). 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 perdidos ainda podem ser abertos por um processo link - se estiverem, você deve recuperá-los desta maneira, em vez de desligar a máquina.

Ainda assim, uma vez que a máquina foi desligada, eu pensei por um tempo e decidi que os arquivos não valiam o investimento de tempo de inicializar um sistema ao vivo para análise forense adequada. Então eu liguei a máquina de volta. E então descobri que meus arquivos ainda estavam no disco: o rm não havia sido propagado para o disco antes de ser desligado. Eu fiz uma pequena dança e agradeci ao deus dos administradores pelo Seu perdão inesperado.

Minha pergunta agora é entender como isso era possível, e qual é o atraso típico antes que um rm seja realmente propagado para o disco. Eu sei que o disco IO não é liberado imediatamente, mas ele permanece na memória por algum tempo, mas achei que o diário de disco garantiria rapidamente que as operações pendentes não fossem perdidas completamente. O link parece sugerir um mecanismo separado para liberar páginas sujas e liberar as operações do diário, mas não fornece detalhes suficientes sobre como revista seria envolvido por um rm , e o atraso esperado antes das operações serem liberadas.

Mais alguns detalhes: os dados estavam em uma partição ext4 dentro de um volume LUKS e, ao inicializar o backup da 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 tenho certeza de que isso esteja relacionado ao rm .

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

    

Answer 1

Parece que você tem uma noção razoável do que aconteceu.

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

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

Agora, como para a revista, esse é um dos equívocos comuns sobre o que a revista é para. A finalidade de um diário não é garantir que as alterações sejam reproduzidas ou que os dados não sejam perdidos. O propósito de um jornal é evitar a corrupção do próprio sistema de arquivos, não dos arquivos contidos nele. A revista simplesmente contém informações sobre as alterações que estão sendo feitas e não (normalmente) os dados completos da alteração em si. Os detalhes exatos dependem do sistema de arquivos e do modo de diário. Para ext3 / 4, consulte a opção data mount em man 8 mount .

Para responder à sua pergunta complementar sobre a possibilidade de impedir as gravações pendentes sem reiniciar:

De fazer uma leitura rápida do código-fonte do kernel, parece que você pode usar o comando magic sysrq u ^{([], [ doc do kernel ])} para fazer uma emergência operação somente leitura de remontagem. Parece que isso irá remontar imediatamente todos os volumes somente leitura sem uma operação de sincronização.

Para usar isto, simplesmente pressione Alt + SysRq + u .

    

Answer 2

De: link

commit=nrsec (*) Ext4 can be told to sync all its data and metadata every 'nrsec' seconds. The default value is 5 seconds. This means that if you lose your power, you will lose as much as the latest 5 seconds of work (your filesystem will not be damaged though, thanks to the journaling). This default value (or any low value) will hurt performance, but it's good for data-safety. Setting it to 0 will have the same effect as leaving it at the default (5 seconds). Setting it to very large values will improve performance.

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

Citado no link acima:

NOTE: clean up memory of unnecessary things (Kernerl 2.6.16 or newer). Always make sure to run sync first to flush useful things out to disk!!!

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