fundo
I ficou sem espaço no /home/data
e necessidade de transferência /home/data/repo
para /home/data2
.
/home/data/repo
contém 1 milhão de diretórios, cada um contendo 11 diretórios e 10 arquivos. Totaliza 2 TB.
/home/data
está no ext3 com o dir_index ativado.
/home/data2
está no ext4. Executando o CentOS 6.4.
Suponho que essas abordagens sejam lentas devido ao fato de repo/
ter 1 milhão de dirs diretamente abaixo dela.
Tentativa 1: mv
é rápido, mas é interrompido
Eu poderia ser feito se isso tivesse terminado:
/home/data> mv repo ../data2
Mas foi interrompido após a transferência de 1,5 TB. Ele estava escrevendo a cerca de 1 GB / min.
Tentativa 2: rsync
rastreia após 8 horas de construção da lista de arquivos
/home/data> rsync --ignore-existing -rv repo ../data2
Demorou várias horas para criar a 'lista de arquivos incrementais' e depois é transferida a 100 MB / min.
Eu o cancelo para tentar uma abordagem mais rápida.
Tentativa 3a: mv
reclama
Testando-o em um subdiretório:
/home/data/repo> mv -f foobar ../../data2/repo/
mv: inter-device move failed: '(foobar)' to '../../data2/repo/foobar'; unable to remove target: Is a directory
Não sei ao certo o que é esse erro, mas talvez cp
possa me salvar.
Tentativa 3b: cp
não chega a lugar algum após 8 horas
/home/data> cp -nr repo ../data2
Ele lê o disco por 8 horas e eu decido cancelá-lo e voltar ao rsync.
Tentativa 4: rsync
rastreia após 8 horas de construção da lista de arquivos
/home/data> rsync --ignore-existing --remove-source-files -rv repo ../data2
Eu --remove-source-files
achava que poderia ser mais rápido se eu começar a limpeza agora.
Demora pelo menos 6 horas para criar a lista de arquivos e depois transfere entre 100 e 200 MB / min.
Mas o servidor ficou sobrecarregado da noite para o dia e minha conexão foi fechada.
Tentativa 5: EXISTEM SOMENTE 300 GB PARA MOVER POR QUE ISSO É TÃO DOLORIZADO
/home/data> rsync --ignore-existing --remove-source-files -rvW repo ../data2
Interrompido novamente. O -W
quase parecia tornar o "envio da lista de arquivos incrementais" mais rápido, o que, na minha opinião, não faria sentido. Independentemente disso, a transferência é terrivelmente lenta e estou desistindo dessa.
Tentativa 6: tar
/home/data> nohup tar cf - . |(cd ../data2; tar xvfk -)
Basicamente, tentando copiar novamente tudo, menos ignorando os arquivos existentes. Ele precisa percorrer 1,7 TB de arquivos existentes, mas pelo menos está lendo a 1,2 GB / min.
Até agora, este é o único comando que oferece gratificação instantânea.
Atualização: interrompida novamente, de alguma forma, mesmo com nohup ..
Tentativa 7: harakiri
Ainda debatendo este
Tentativa 8: 'mesclar' com script com mv
O diretório de destino tinha cerca de 120 mil diretórios vazios, então eu corri
/home/data2/repo> find . -type d -empty -exec rmdir {} \;
Script Ruby:
SRC = "/home/data/repo"
DEST = "/home/data2/repo"
`ls #{SRC} --color=never > lst1.tmp`
`ls #{DEST} --color=never > lst2.tmp`
`diff lst1.tmp lst2.tmp | grep '<' > /home/data/missing.tmp`
t = `cat /home/data/missing.tmp | wc -l`.to_i
puts "Todo: #{t}"
# Manually `mv` each missing directory
File.open('missing.tmp').each do |line|
dir = line.strip.gsub('< ', '')
puts `mv #{SRC}/#{dir} #{DEST}/`
end
FEITO.
mv
novo? Em teoria mv
, somente o arquivo de origem será excluído se o arquivo de destino tiver sido completamente copiado, portanto deve funcionar bem. Além disso, você tem acesso físico à máquina ou isso é feito através de uma ssh
conexão?
mv
não perdoa, se você ficar desconectado, poderá perder dados e nem saber. Como você disse que está fazendo isso de novo ssh
, eu recomendo usar screen
e desanexar. Habilite o log e acompanhe esse caminho. Se você estiver usando verbos, levará mais tempo. Também tenteiotop
screen
. Eu estava pensando em detalhes, mas acho que é tarde demais para reiniciar tar
agora. E iotop
tem sido a minha utilidade favorito para os últimos dias :)