Como limpar diários no sistema de arquivos ext3 / ext4? [fechadas]

Question

Alguns preâmbulos: Estou fazendo cópias bit a bit de dispositivos de disco (via dd command) de hosts gêmeos (ou seja, com o mesmo layout de hardware virtualizado e pacotes de software, mas com histórico de uso diferente). Para otimizar o tamanho da imagem, tracei todo o espaço vazio em partições com zeros (por exemplo, de /dev/zero ). Também estou ciente de blocos reservados por partição e reduzi temporariamente esse valor para 0% antes de navegar.

Mas estou curioso sobre a discrepância das imagens compactadas finais (por bzip2 ). Todos os hosts têm quase o mesmo tar-gziped tamanho de arquivos, mas dd imagens compactadas têm uma variedade significativa (até 20%). Então, como poderia ser? Existe uma razão nos dados dos periódicos do sistema de arquivos que eu não pude depurar? Existem mais de dez partições no host e cada uma relatada de tamanho de diário de 128Mb. (Também verifiquei a desfragmentação, está tudo ok: 0 ou 1 devido ao relatório da ferramenta e4defrag )

Então, minha pergunta é possível de alguma forma limpar os diários do sistema de arquivos ext3/ext4 ? (com segurança para dados armazenados, claro:)

ESCLARECIMENTO
Eu perguntei indubitavelmente sobre como limpar (remover / atualizar) diários em ext3/ext4 filesystem se possível ou talvez eu esteja enganado e não há tal recurso como recuperar espaço em disco ocupado por periódicos de sistema de arquivos, então todas as soluções são bem vindas. A intenção de fazer a pergunta que coloquei como premissa no preâmbulo e a resposta à minha pergunta me ajudaria a investigar o problema que encontrei.

    

Answer 1

Você pode limpar o diário desmontando ou remontando somente leitura (possivelmente uma boa ideia ao clonar). Com o ext4, você também pode desativar o diário ( tune2fs -O ^has_journal ), o arquivo imutável .journal magic será removido automaticamente. Os dados do diário ainda estarão no disco subjacente, portanto, a remoção do diário e o preenchimento zero do espaço livre podem obter os melhores resultados.

Os comentários acima acertaram em cheio, no entanto, dd vê os bits sob o sistema de arquivos, como eles chegaram a um arranjo particular depende de todas as coisas que aconteceram ao sistema de arquivos, e não apenas do final conteúdo dos arquivos. Recursos como pré-alocação, alocação atrasada, alocação de vários blocos, timestamps de nanossegundos e, é claro, a própria revista contribui para isso. Além disso, há uma estratégia de alocação potencialmente aleatória: o alocador Orlov pode voltar aleatoriamente alocação (veja fs/ext4/ialloc.c ).

Para ser completo, o recurso de exclusão segura com depuração aleatória também contribuiria para as diferenças (supondo que você tenha excluído seus arquivos de lastro com zero ), embora esse recurso não seja (ainda) mainline.

Em muitos sistemas, os comandos dump e restore podem ser usados para um método de clonagem semelhante, por várias razões nunca pegou no Linux.

    

Answer 2

Encontrei a causa raiz do problema, por isso, quando decidi verificar a cópia bit a bit de cada partição em vez do disco inteiro para ver como os dados redundantes são distribuídos, percebi que /dev/mapper obteve lv_swap volume (partição) o mesmo disco que foi capturado e os dados de troca foram incluídos na imagem final. Todo o delta de variedade de tamanho de imagem estava localizado naquela partição de swap ... nenhuma meta mágica de FS .. Eu não a vi antes porque meu script pega informações do comando df onde lv_swap não é calculado.

De qualquer forma, se alguém responder a pergunta sobre a limpeza de diários no sistema de arquivos ext3/ext4 , eu o aceitarei.