☰

Efeito de matar um comando rm de longa duração

tag-icon • tag-icon linux rm
Efeito de matar um comando rm de longa duração

Hoje excluí um arquivo de 50 GB armazenado em um sistema de arquivos ext3 usando o rmcomando. Foram necessários rmquase 40 minutos de intensas E/S para liberar todos os blocos. Pelo que vejo em outras fontes, é o tempo que leva para liberar todos os blocos usados ​​pelo arquivo. O que teria acontecido se alguém interrompesse o rmprocesso no meio. Isso poderia ter causado uma corrupção no sistema de arquivos, com alguns blocos que não puderam mais ser recuperados como espaço livre?

Responder1

(ou seja, exigindo fsck). Nenhuma inconsistência no sistema de arquivos é necessária.

Sim, a liberação do bloco acontecerá após a desvinculação. Mas este processo não será interrompível.

ext2_evict_inode->

__ext2_truncate_blocks ->
ext2_free_branches -> (for loop)
sb_bread ->
wait_on_buffer ->

wait_on_bit_io(&bh->b_state, BH_Lock, TASK_UNINTERRUPTIBLE);

O exemplo acima é para ext2, pensei que seria mais simples de ver. ext3não vai ser diferente...

ext4deveria ser mais rápido. O uso de extensões deve evitar a necessidade deblocos triplo-indiretos. (O artigo descreve a adição de extensões ao ext3, mas Linus hesitou e disse para aumentar o número da versão para ext4 primeiro). Espero que o tempo de atualização dos bitmaps seja o mesmo, mas eles são muito mais compactos que os ponteiros de bloco.

informação relacionada