ext2 dump / restore problema

Question

Estou executando um servidor de email com armazenamento maildir. Isso significa que muitos arquivos são criados e acabei de ficar sem inodes. AFAIK não há nenhum comando mágico para aumentar o número de inodes no sistema de arquivos ext # (ou estou errado?), Então eu tenho que fazer backup e restaurar todo o sistema de arquivos. Mas como eu faço isso? Eu tentei criar outra partição e fazer:

dump -f - -0 /vservers/mail | restore rf - -u -v

Enquanto isso parece funcionar, demora muito mais do que estou disposto a esperar (ele conseguiu criar 500 diretórios vazios em 2 horas antes de eu parar o processo; strace mostrou que a restauração estava chamando muitos leekks inúteis). Existe algum outro método para copiar o sistema de arquivos completo (incluindo sockets, arquivos de dispositivos, proprietários, permissões, acls, etc)? Informação adicional: source fs é ext3, destination was ext4, filesystems estão em lvm, o fs que eu quero mover é root fs para vserver.

    

Answer 1

Minha sugestão alternativa para copiar o sistema de arquivos é a seguinte. Tenha em mente que o mais próximo que cheguei deste problema é usar find + xargs + rm para limpar um maildir que ficou louco com lixo inútil, então você deve ver onde isso vai chegar depois de uma hora.

cd root_of_source ; find . -print0 | tar -c --null -T - -f - | tar -sxf - -C root_of_target

A função desta construção é

• Recupere a lista de arquivos em sua ordem crua
  • É por isso que eu uso o find ao invés do padrão do tar ... Eu não sei se o padrão do tar é ruim, só sei que o find é bom,
• Transmita essa lista para o tar null terminado (para que todos os caracteres especiais sejam manipulados corretamente).
• Pegue a saída do formato tar e descompacte o resultado (sem reclassificar a entrada (-s)) no diretório de destino.

Independentemente do método usado:

• Se esses dados forem iniciados e terminados nos mesmos discos físicos, seu desempenho naturalmente irá sugar muito em comparação às operações normais (muitas buscas entre a leitura da origem e a gravação no destino).
• Se você tem alguma CPU disponível, uma pequena compactação não deve prejudicar, e pode ajudar Apenas adicione um estágio 'gzip -c -1' entre os comandos tar e um -z para o segundo tar.

Answer 2

Você já pensou em tentar usar o unionfs para unir o sistema de arquivos existente com um novo, com as gravações indo para o novo sistema de arquivos?

Eu nunca usei o UnionFS, mas o que ouvi sobre isso parece que ele pode deixar você ir ao ar e começar a gravar dados no disco novamente sem ter que recriar o sistema de arquivos unindo o sistema de arquivos existente como somente leitura, com um novo sistema de arquivos como o sistema de arquivos gravável. Pode haver ocorrências de desempenho ou outros problemas que tornam isso desnecessário, mas se você estiver apenas procurando ideias e tiver algum tempo enquanto o dump está em execução, provavelmente é possível pesquisar isso em um conjunto viável de comandos.

    

Answer 3

Diferente de dump | restore , você pode usar tar | tar ou apenas cp -ax ou rsync para copiar todos os arquivos para o novo fs. Na minha experiência, dump | restore é o método mais rápido.

Para referência, em uma máquina bastante antiga e lenta, eu levo 35 minutos para duplicar um fs usando dump | restore onde o fs tem 420.774 inodes usando 7,8 GB de espaço.

Por comparação, leva 61 minutos usando tar | tar e 64 minutos usando cp -ax .

Há alguns meses, publiquei um patch para tornar dump mais rápido, mas foi depois que 0,4b44 foi lançado, e ainda não houve outro lançamento. Você pode encontrar o patch na lista de discussão . Construir o próprio 0.4b44 com este patch aplicado pode fazer uma diferença significativa. Para mim, reduziu o tempo de 35 minutos para apenas 25. O feedback na lista de discussão seria útil.