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

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

Quando copio arquivos grandes em um pen drive, por exemplo, a janela de progresso mostra uma estimativa de que na maioria das vezes não falha em mostrar o tempo real e a porcentagem para concluir, mas há casos em que diz que tudo está concluído e a janela de progresso fecha. Vou extrair o pen drive e ele diz que ainda está em uso. Depois de verificar o pen drive, vejo que ele ainda está copiando os arquivos, mas não há janela de progresso mostrando isso.

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

Não quero saber como corrigi-lo, pois li a profundidade de 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 e a quantidade de influência do arquivo na estimativa correta. Por exemplo, 1 arquivo de 4 GB ou 1000 arquivos de 4 MB.

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

Existem outras perguntas semelhantes a isso, como copiar arquivos para o pendrive nunca terminados, mas estou mais focado na mecânica sobre por que ele se comportaria assim.

Eu suponho que você esteja usando o Nautilus como seu gerenciador de arquivos e, se houver, existem erros antigos sobre isso. Muito numinous para mencionar afetando Mint, Fedora, Red Hat e tudo o mais. O Ubuntu não está sem esse mesmo problema.

Alguns sugerem que desativar a exibição de miniaturas ajuda. Outros depositam suas esperanças no "mais novo kernel", mas isso ainda existe.

O problema = Começa rápido e depois fica mais lento 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 ao redor parece ser sudo cp /filetobecopied /dev/nameofdevice

outro postado aqui diz que "copiar em pedaços" funciona. Não confirmado da minha parte.

Esta também é uma boa resposta com uma solução: /unix//a/181236 Diz:

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

Infelizmente, o programa não pode dizer quanto tempo levará para liberar o buffer porque ele não sabe.

Se você quiser tentar alguns truques para usuários avançados, poderá reduzir o tamanho do buffer usado pelo Linux configurando / proc / sys / vm / dirty_bytes para algo como 15728640 (15 MB). Isso significa que o aplicativo não pode ter mais de 15 MB à frente de seu progresso real.

Um efeito colateral é que seu computador pode ter uma taxa de transferência de gravação de dados mais baixa com essa configuração, mas, no geral, acho útil ver que um programa está em execução por um longo tempo enquanto grava muitos dados versus a confusão de ter um O programa parece ter sido concluído com o seu trabalho, mas o sistema está muito atrasado, pois o kernel faz o trabalho real. A configuração de dirty_bytes com um valor razoavelmente pequeno também pode ajudar a impedir que o sistema deixe de responder quando você está com pouca memória livre e executa um programa que repentinamente grava muitos dados.

Mas não o ajuste muito pequeno! 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".