copie um grande número de arquivos sobre o ssh

Question

Eu montei um servidor remoto em ssh (usando sshfs). Eu quero copiar um grande número de arquivos do servidor remoto para local:

cp -rnv /mounted_path/source/* /local_path/destination

O comando executa a cópia recursiva que não sobrescreve os arquivos existentes. Mas o processo de cópia é bastante lento. Percebi que não copia arquivos em ordem. Então, minha pergunta é: posso acelerar o processo de cópia abrindo vários terminais e executando o mesmo comando acima? Um processo de cópia é inteligente o suficiente para não sobrescrever os arquivos copiados por outros processos?

    

Answer 1

… para responder à pergunta original, como afirmado…

Há duas coisas para discutir aqui.

Usando o SSHFS

O SSHFS usa o "subsistema" SFTP do protocolo SSH para fazer um sistema de arquivos remoto aparecer como se fosse montado localmente.

Uma coisa crucial aqui é notar que o SSHFS traduz baixo nível syscalls em relativamente comandos SFTP de alto nível que são então traduzidos para os syscalls executado no servidor pelo servidor SFTP e, em seguida, seus resultados são enviado de volta para o cliente e traduzido para trás.

Existem várias fontes de lentidão com este processo:

• Existem syscalls distintos para operações distintas em arquivos, e eles são executados na ordem em que o cliente os emite. Diga, o cliente stat(2) -s as informações em um arquivo então open(2) -s esse arquivo então lê seus dados - executando vários read(2) chama em uma linha e, finalmente, close(2) -s o arquivo, todos esses syscalls têm que ser traduzidos para comandos SFTP, enviados para o servidor e processado lá com seus resultados enviados de volta para o cliente, traduzida de volta.

• Mesmo quando o SSHFS parece implementar certos hacks inteligentes, como "read ahead" (especulativamente lê mais dados do que o solicitado pelo cliente), Ainda assim, cada syscall resulta em uma viagem de ida e volta ao servidor e volta. Ou seja, enviamos os dados para o servidor e esperamos que eles respondam processar sua resposta. IIUC, SFTP não implementa "pipelining" - um modo de operação em que enviamos comandos antes de serem concluídos, Então, basicamente, cada syscall. Embora seja tecnicamente possível para ter tal processamento até certo ponto, sshfs não parece implementá-lo.

  IOW, cada syscall cp na sua máquina cliente faz, é traduzido a um pedido para o servidor seguido de esperar por ele para responder e, em seguida, recebendo sua resposta.

Vários processos cp -n são executados em paralelo

A resposta para a questão de saber se é aceitável empregar vários processos cp -n copiando arquivos em paralelo depende de várias considerações.

Primeiro, se todos eles passarem pela a mesma montagem SSHFS, haverá obviosly nenhum aumento de velocidade, já que todos os syscalls emitidos por múltiplos cp irão eventualmente atingir a mesma conexão do cliente SFTP e será serializada por ele devido às razões explicadas acima.

Segundo, executando várias instâncias de cp -n executando distintas Os pontos de montagem do SSHFS podem valer a pena - até os limites fornecidos pelo taxa de transferência de rede e a taxa de transferência de E / S pelo meio / mídia sob o sistema de arquivos de destino. Nesse caso, é crucial entender que, como o SSHFS não usa travando no servidor, as diferentes instâncias de cp -n devem operar em hierarquias de diretórios distintas - simplesmente para não pisar nos dedos uns dos outros.

Diferentes abordagens / mais sensatas

Primeiro, o fluxo de dados de tubulação criado por tar , cpio ou outro fluxo arquivador e processá-lo remotamente tem a vantagem de que todas as viagens de ida e volta as operações do sistema de arquivos são evitadas: o arquivador local cria o fluxo tão rápido quanto a taxa de transferência de E / S no sistema de arquivos de origem permite e envia-o o mais rápido que a rede permitir; os extratos do removedor de archiver dados do fluxo e atualiza seu sistema de arquivos local o mais rápido possível. Não há viagens de ida e volta para executar "comandos" elementares: você apenas vai tão rápido quanto o ponto de E / S mais lento deste pipeline permite; é simplesmente impossível ir mais rápido.

Em segundo lugar, outra resposta sugeriu usar rsync e você rejeitou sugestão com base em

rsync is slow as it has to checksum the files.

Isto está simplesmente errado. Para citar a página de manual rsync :

-c, --checksum

This changes the way rsync checks if the files have been changed and are in need of a transfer. Without this option, rsync uses a "quick check" that (by default) checks if each file's size and time of last modification match between the sender and receiver. This option changes this to compare a 128-bit checksum for each file that has a matching size.

e

-I, --ignore-times

Normally rsync will skip any files that are already the same size and have the same modification timestamp. This option turns off this "quick check" behavior, causing all files to be updated.

--size-only

This modifies rsync's "quick check" algorithm for finding files that need to be transferred, changing it from the default of transferring files with either a changed size or a changed last-modified time to just looking for files that have changed in size. This is useful when starting to use rsync after using another mirroring system which may not preserve timestamps exactly.

e finalmente

--existing skip creating new files on receiver

--ignore-existing skip updating files that exist on receiver

Isto é,

• Por padrão, rsync não hash o conteúdo do arquivo para ver se um arquivo mudou.
• Você pode dizer que ele se comporta exatamente como cp -n , ou seja, pular a atualização um arquivo, se ele existir apenas no controle remoto.

Answer 2

Eu recomendaria usar duas instâncias de tar ou cpio provenientes de um canal SSH, como em

$ tar -C src/path -cf - . | ssh user@server tar -C dst/path -xf -

Essa abordagem tem a vantagem de consumir "full pipe" com um único fluxo de dados (você também pode inserir | pv entre para ver como funciona se desejar alguma interatividade) em comparação com SSHFS (e SFTP ) que faz muitas viagens entre o servidor e o cliente.

O ponto crucial aqui é que o SSH não é meramente sobre o "login remotamente", que muitas pessoas supõem que seja, - é um pouco sobre executar qualquer comando remotamente enquanto conecta seus fluxos padrão de I / O para a instância do cliente SSH local.

Observe que, se isso acontecer em uma LAN segura ou em outro ambiente controlado, é melhor abandonar o SSH e usar um par de instâncias de nc ou socat - a de escuta no servidor e a de envio em um cliente. Essa abordagem não gasta os ciclos da CPU na criptografia dos dados, portanto você provavelmente ficará limitado pela E / S em um dos três componentes: o FS de origem, a rede e o FS de destino.

    

Answer 3

Não, o processo de cópia não é inteligente para não sobrescrever os arquivos copiados por outros processos. A execução de vários comandos para copiar os mesmos arquivos / pastas não é uma boa ideia.

Às vezes, você não pode fazer muito quando as máquinas de origem e de destino estão muito distantes e a rede está lenta. Aqui está uma postagem para discutir por que o SSHFS é lento.

    

Answer 4

Sugiro que você use rsync com avP flags. Exemplo:

rsync -avP <Source>  <Destination>