Por que ao copiar para uma unidade externa, a janela de progresso não está correta

Question

Sinta-se à vontade para editar o título e explicar melhor o que vou escrever aqui.

Quando eu copio arquivos grandes para um pen drive, por exemplo, a janela de progresso mostra uma estimativa que na maioria das vezes não mostra o tempo real e o percentual para terminar, mas há casos em que diz que tudo está terminado e a janela de progresso é fechada. Eu vou extrair o pen drive e ele diz que ainda está em uso. Depois de verificar o pen drive, vejo que ainda está copiando os arquivos, mas não há uma janela de progresso mostrando isso.

Isso não acontece apenas com arquivos grandes, mas também acontece com muitos arquivos pequenos. Se eu copiá-los, a barra de progresso pode dizer 15 segundos por exemplo e terminar nesse tempo, mas o tempo real pode ser de 1 minuto e nos próximos 45 segundos eu preciso realmente olhar para a luz no pen drive para ver se há é uma atividade real.

Eu não quero saber como consertá-lo, já que li o quão profundo pode ser uma correção para isso. O que eu quero saber é por que a janela de progresso mostra uma estimativa que não corresponde ao processo de cópia.

É dependente do cache na unidade externa?

O tamanho do arquivo e a quantidade de arquivos influenciam na estimativa correta. Por exemplo, 1 arquivo de 4 GB ou 1000 arquivos de 4 MB.

Há opções de configuração que podem alterar o comportamento.

Existem outras questões semelhantes a isto, como copiando arquivos para o pendrive nunca terminado , mas estou mais focado na mecânica em relação a por que ela se comportaria assim.

    

Answer 1

Eu suponho que você esteja usando o Nautilus como seu gerenciador de arquivos e, nesse caso, há bugs antigos sobre isso. Demasiado numinoso para mencionar o efeito Mint, Fedora, Red Hat e tudo o mais. O Ubuntu não está sem esse mesmo problema.

Alguns sugerem desativar as visualizações de miniaturas. Outros depositam suas esperanças no "kernel mais novo", mas isso ainda existe.

O problema = Começa rápido, então vai mais devagar Isso ocorre porque quando montado com async, ele grava no cache, quando o cache está cheio, você vê a velocidade de gravação "Real".

O trabalho parece ser sudo cp /filetobecopied /dev/nameofdevice

outro publicado aqui diz que "copiar em partes" funciona. Não confirmado da minha parte.

    

Answer 2

Esta também é uma boa resposta com uma solução: link Diz:

  

A razão pela qual isso acontece é que o programa diz "escreva isso   dados "e o kernel linux copia para um buffer de memória que é   na fila para ir para o disco e, em seguida, diz "ok, pronto". Então o programa pensa   copiou tudo. Então o programa fecha o arquivo, mas   de repente, o kernel faz esperar enquanto esse buffer é empurrado para fora   disco.

     

Então, infelizmente, o programa não pode dizer quanto tempo levará para   libere o buffer porque ele não sabe.

     

Se você quiser experimentar alguns truques do usuário avançado, pode reduzir o tamanho de   o buffer que o Linux usa definindo / proc / sys / vm / dirty_bytes para   algo como 15728640 (15 MB). Isso significa que o aplicativo não pode   mais de 15MB à frente de seu progresso real.

     

Um efeito colateral é que seu computador pode ter uma menor gravação de dados   taxa de transferência com essa configuração, mas no geral, acho útil   ver que um programa está sendo executado há muito tempo enquanto grava muitos dados   contra a confusão de ter um programa parece ser feito com o seu trabalho   mas o sistema está ficando mal como o kernel faz o trabalho real.   Configurar dirty_bytes para um valor razoavelmente pequeno também pode ajudar a evitar   seu sistema de não responder quando você está com pouca memória livre   e executar um programa que de repente grava muitos dados.

     

Mas não o defina muito pequeno! Eu uso 15MB como uma estimativa aproximada de que o   kernel pode liberar o buffer para um disco rígido normal em 1/4 de segundo   ou menos. Isso evita que meu sistema fique "lento".