Agora eu sei que você não deve colocar 10 milhões de arquivos em um único diretório para começar. A culpa é dos desenvolvedores, mas é onde eu estou. Nós vamos corrigi-lo e movê-los para grupos de pastas, mas primeiro temos que copiá-los da caixa de produção.
Primeiro tentei o rsync, mas ele falharia miseravelmente. Eu suponho que foi porque armazenar o nome e caminho dos arquivos na memória foi maior que o espaço de memória RAM e de troca.
Então eu tentei compactar tudo em um tar.gz, mas ele não podia descompactá-lo, arquivar um erro muito grande (era 60gigs).
Eu tentei apenas fazer um tar para exação de tar, mas eu tenho um "não pode abrir: arquivo muito grande"
tar c images/ | tar x –C /mnt/coverimages/
Informação extra:
/ mnt / coverimages / é um compartilhamento nfs para o qual queremos mover as imagens.
Todos os arquivos são imagens
OS: Gentoo
Se você instalar a versão 3+ do rsync, ela fará uma lista contínua de arquivos para transferir e não precisará manter toda a lista de arquivos na memória. No futuro, você provavelmente desejará considerar o hash dos nomes de arquivos e a criação de uma estrutura de diretório baseada em partes desses hashes.
Você pode ver esta resposta para ter uma ideia do que quero dizer com hashing.
Se eu pudesse organizar o tempo de inatividade, eu simplesmente moveria o disco temporariamente.
você já tentou usar find e -exec (ou xargs), algo como
find images/ -exec cp "{}" /mnt/coverimages/ \;
?
Eu não acho que você tenha o comando "tar | tar" corretamente. Tente isto
tar cf - images/ | cd /mnt/coverimages && tar xf -
Outra opção seria transmitir via SSH (alguma sobrecarga de CPU para criptografia):
tar cf - images/ | ssh user@desthost "cd /path/coverimages && tar xf -"
Há também o cpio, que é um pouco mais obscuro, mas oferece funcionalidade semelhante:
find images/ | cpio -pdm /mnt/coverimages/
Eu imagino que suas duas opções são mover incrementalmente o conjunto de arquivos usando regexes para corresponder nomes de arquivos, ou desmontar o sistema de arquivos e copiar todo o dispositivo.
uau. Boa sorte.
Segmente seus rsyncs ou qualquer ferramenta que você use em vários trabalhos. Se os arquivos são nomeados com algum tipo de lógica ou numeração, você poderia dizer ao sistema para rsync o número X de arquivos por vez.
Se você já tem uma montagem nfs, não basta um simples cp -au?
Eu acredito que um tar-over-network (ssh ou netcat) poderia ser mais rápido (menos espera por viagens de ida e volta).
Além disso, investigue a ionização de antemão - seus usuários de produção agradecerão a você
Uma nota, classicamente, as gravações do NFS eram síncronas, portanto, o desempenho seria melhor se você exportasse o diretório do qual está lendo e, em seguida, escreveu localmente.
Eu acho que a solução find é a melhor escolha (hmmm, eu me pergunto sobre como usar nohup ou algo parecido, e gerar um processo em segundo plano para acelerar um pouco as coisas, mas isso pode não ser uma vitória). Find significa que você está apenas caminhando pelo diretório e lidando com cada arquivo à medida que o encontra, o que significa que você nunca está pensando em toda a lista de arquivos.
Pode haver uma maneira de separar todos os arquivos em diretórios separados e, em seguida, criar um único diretório que contenha apenas hard links para esses arquivos? Dessa forma, seus desenvolvedores poderiam acessar os arquivos de qualquer forma, como um único diretório ou como diretórios separados (separados por mês, por exemplo):
/home/user/directory/file1-slink
/home/user/directory/file2-slink
/home/user/dir-month-07/file1
/home/user/dir-month-06/file2