Copiar para o cartão de memória USB muito lento?


45

Quando copio arquivos para o dispositivo USB, leva muito mais tempo do que no Windows (mesmo dispositivo USB, mesma porta) é mais rápido que as velocidades USB 1.0 (1MB / s), mas muito mais lento que as velocidades USB 2.0 (12MB / s). Copiar 1,8 GB leva mais de 10 minutos (deve ser <3 min.) Eu tenho dois cartões idênticos SanDisk Cruzer de 8 GB e tenho o mesmo problema com ambos. Eu tenho um super talento SSD USB de 32 GB na porta vizinha e funciona nas velocidades esperadas.

O problema que pareço ver na GUI é que a barra de progresso chega a 90% quase instantaneamente, é 100% um pouco mais lenta e fica parada por 10 minutos. Interromper a cópia neste momento parece resultar em corrupção no final do arquivo. Se eu esperar que a cópia seja concluída com êxito.

Alguma ideia? saída dmesg abaixo:

[64059.432309] usb 2-1.2: new high-speed USB device number 5 using ehci_hcd
[64059.526419] scsi8 : usb-storage 2-1.2:1.0
[64060.529071] scsi 8:0:0:0: Direct-Access     SanDisk  Cruzer           1.14 PQ: 0 ANSI: 2
[64060.530834] sd 8:0:0:0: Attached scsi generic sg4 type 0
[64060.531925] sd 8:0:0:0: [sdd] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
[64060.533419] sd 8:0:0:0: [sdd] Write Protect is off
[64060.533428] sd 8:0:0:0: [sdd] Mode Sense: 03 00 00 00
[64060.534319] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.534327] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.537988] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.537995] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.541290]  sdd: sdd1
[64060.544617] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.544619] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.544621] sd 8:0:0:0: [sdd] Attached SCSI removable disk

O Linux adia gravações de disco em troca de executar outras tarefas mais rapidamente. Apenas um palpite, tente executar synce veja se isso não acelera o processo. <- não testado, mas possível
— RobotHumans

isso não faz sentido que o adie para um tipo de USB, mas não para outro. Também me lembro de chamadas linux sincronizar a cada 30 segundos ou mais? Pode estar desatualizado. Espero que este seja algum tipo de problema de driver ou compatibilidade, pois depende do tipo de dispositivo.
— Eloff

Ser mais rápido em outros pendrives USB não está na sua pergunta. Se fosse, eu teria sugerido procurar no hdparm. Portanto, faz sentido se você vê-lo a partir da perspectiva de alguém que não conhece todo o seu set-up, mas depende de sua pergunta para mais detalhes
— RobotHumans

"Eu tenho um super SSD USB de 32 GB na porta vizinha e funciona nas velocidades esperadas". estava lá, mas bem escondido, vou admitir :) Então, o que é esse material hdparm que você alude?
— Eloff

Ok, SSD e memória flash NÃO são a mesma coisa. Mas se movendo ao longo, hdparm é um utilitário que permite o acesso set / velocidades de rotação para a unidade manualmente
— RobotHumans

Respostas:


29

Por que a cópia na minha unidade USB é tão lenta no Linux (e mais rápida no Windows)?

Razão 1. O armazenamento em cache do arquivo pode fazer com que as gravações pareçam mais lentas ou mais rápidas

O problema que pareço ver na GUI é que a barra de progresso chega a 90% quase instantaneamente, é 100% um pouco mais lenta e fica parada por 10 minutos.

Uma coisa que você precisa entender é o cache de arquivos. O Linux (e Windows) usará a RAM "vazia" para armazenar em cache as operações de leitura / gravação e torná-las mais rápidas nos acessos subseqüentes. O armazenamento em cache de operações de cópia para reduzir a velocidade dos dispositivos resulta no comportamento que você vê - a "conclusão rápida" está realmente gravando no cache e diminui e pára porque a liberação real dos dados no cache (sincronização) para o dispositivo lento é demorando muito tempo. Se você abortar nesse ponto, os dados serão corrompidos (como você observou), pois a sincronização nunca terminou.

Essa cópia no Windows pode parecer mais rápida (incluindo as velocidades informadas de MB / s) porque, às vezes, o Windows não espera a sincronização e declara o trabalho concluído assim que os dados são gravados no cache.

Razão 2. A gravação de muitos arquivos, especialmente os pequenos, é lenta

Para copiar 1,8 GB

Devido à maneira como a memória flash e os sistemas de arquivos funcionam, a taxa de transferência mais rápida (velocidade) é alcançada ao gravar arquivos muito grandes. Escrever muitos arquivos pequenos ou até dados misturados que contêm vários arquivos pequenos pode atrasar bastante o processo. Isso afeta também os discos rígidos, mas em menor grau.

Razão 3. As velocidades de gravação de um pendrive e um SSD não podem ser comparadas

Eu tenho um super talento SSD USB de 32 GB na porta vizinha e funciona nas velocidades esperadas.

  • Geralmente, um pendrive USB tipo jardim consiste em chips de memória flash que são gravados em série (sequencialmente) e não possuem cache próprio.

  • Um SSD, por outro lado, contém um controlador que grava paralelamente nos chips de memória flash , aumentando a taxa de transferência em um fator de 2 ou mais no pen drive.

    • Se o seu SSD de 32 GB tivesse chips de 4x 8 GB, ainda seria 4x mais rápido que o pen drive em qualquer operação de gravação.
    • O SSD também contém cache de RAM (como discos rígidos), para que possa armazenar rapidamente os dados recebidos no cache e informar ao sistema operacional o que foi feito, enquanto ainda precisa gravar esses dados na memória flash.
  • Portanto, com um arquivo grande, seus 32 GB de GB com a estrutura 4x que assumimos seria 4x mais rápido; com muitos arquivos pequenos, seria 10x ou mais rápido porque poderia armazená-los de maneira inteligente em seu cache.


Em resumo , essas são as razões pelas quais a cópia de arquivos em pen drives pode parecer mais lenta no Linux. É realmente mais lento por causa de um problema de hardware / driver ou o que seja ....

Fazendo uma comparação adequada das velocidades de gravação entre Linux e Windows

  • Antes de tudo, esqueça o SSD por causa da razão 3. É como laranjas e maçãs.
  • Para negar os efeitos do motivo 1 (armazenamento em cache) e do motivo 2 (arquivos pequenos), você precisa testar com um único arquivo grande, maior que a quantidade de RAM no sistema de teste.
  • No Linux, você pode criá-lo dd if=/dev/urandom of=largetest bs=1M count=7500, o que fornece um arquivo de teste de 7500 MB. Supondo que seu sistema tenha menos de 4 GB de RAM, é bom o suficiente. Copie isso para um cartão Sandisk de 8 GB recém-formatado e agilize o tempo.
  • Reinicie no Windows e copie largetestdo pen drive para o disco rígido. Reinicie novamente (para removê-lo do cache). Em seguida, formate o pendrive (o mesmo vfat / FAT32!) E copie largetestdo disco rígido para o pendrive.
  • Como os tempos se comparam?

2
cc: @Eloff Re Motivo 1 : Sim, a sincronização de cache certamente pode afetar o tempo aparente de gravação. Mas o cache explicaria sozinho por que ele fica lá por 10 minutos ? Acho que precisamos de mais detalhes do OP. Re Razão 2 : Por que você assume esta transferência consistia de muitos arquivos pequenos? Eu não acho que o OP fornece detalhes sobre essa transferência de 1,8 GB, não é? Re Razão 3 : Sim, SSD é um animal diferente. Provavelmente também seria conectado via SATA e não USB. Acho que o OP simplesmente falou mal e se referiu a um dispositivo USB como um SSD. Mas, novamente, não há como saber, a menos que obtenhamos mais detalhes do OP.
— irracional John

2
Essa resposta ignora descaradamente como a pergunta foi formulada. A pergunta fala claramente sobre um arquivo grande e o fato de interromper a cópia resulta em um arquivo mutilado.
— Zrajm

4
@zrajm isso é verdade. No entanto, para pessoas como eu esbarrando no mesmo problema, isso é muito útil.
— Pithikos

Como desativar esse comportamento de cache, então?
— Aminu Kano

7

A correção encontrada foi tudo o que fiz foi desmontar, remover a unidade e executar sudo modprobe ehci_hcdno terminal. Insira drive e agian sudo modprobe ehci_hcdquando eu colocar o drive e wow 20 / mbs, pensei em compartilhar. Espero não ter que fazer isso toda vez ... mas não é tão difícil ...

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177235 diz que eles corrigiram o bug.


A sério?? Esse relatório de bug é de dezembro de 2007 e faz referência ao Ubuntu gutsy 7.10. (FYI: @MarcoCeppi)
— irracional John

3
@irrationalJohn Não forneci a resposta, apenas a limpei. Em segundo lugar, apenas porque um relatório de bug é antigo, não significa que ele ainda não é válido. Está sendo triado de acordo com isso
— Marco Ceppi

@MarcoCeppi Sim, eu sei que você editou apenas. Por isso prefaciei " FYI: ". Imaginei que, se você o editasse, poderia (ou não ) estar interessado. Imaginei que, se você não se importasse, simplesmente ignoraria o aviso. Quanto a um relatório de bug antigo ainda tendo relevância ... Há mais de 4 anos e acho que pelo menos 8 (?) Lançamentos mais tarde? Para um bug de desempenho? Claro, pode ser possível, mas não é o primeiro lugar que eu procuraria. FWIW.
— irracional John

7

Eu acho que as chances são muito baixas de que seja um problema de porta. É mais provável que seja um problema de LINUX (ou configuração de linux) - navegue e você encontrará milhares de relatórios de problemas sobre USB lento no linux / ubuntu. Para mim, é quase um empecilho para o linux - agora tenho um Ubuntu 12.04 LTS e ainda tenho esse problema (então prefiro usar a instalação do Win7 - principalmente / somente por causa disso). Esse problema (ou algo com sintomas semelhantes) já existe há vários anos, aparentemente sem solução. E durante esse tempo, tentei vários PCs físicos com várias versões diferentes do ubuntu (configuração padrão) e 2-3 diferentes pen drives ....


5

Apenas umounto dispositivo, se já estiver montado automaticamente, e monte-o manualmente /mnt/foldername.

No meu caso,

umount /media/usb0
mount /dev/sdb1 /mnt/sam

Depois disso, ele está lidando muito rápido.


Isso, juntamente com em rsyncvez de, cpparece fazer o truque.
— precisa saber é

19
Isso não fez nenhuma diferença para a minha situação. Além disso, essa não é realmente uma solução sem alguma teoria sobre por que isso deveria fazer a diferença.
— LondonRob

@Irfan Não, rsync faz abrandar também ...
— sergzach

3

É 2019 e ainda estou tendo o mesmo problema. Então, pensei em pesquisar na internet por uma solução. Encontrei a seguinte página que sugere uma: https://gist.github.com/2E0PGS/f63544f8abe69acc5caaa54f56efe52f

Diz:

Execute os seguintes comandos em um console para verificar se isso resolve o problema. Você pode precisar sudo suprimeiro ter a permissão necessária.

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

Se funcionar, você poderá fazer essa alteração persistente nas reinicializações colando as duas linhas no final do seu /etc/rc.localarquivo.

Para mim, teve o seguinte efeito:

Antes de copiar arquivos grandes para uma unidade USB, começava muito rápido (como 60 MB / s) e ficava cada vez mais lento (<10 MB / s) até parecer que nunca iria terminar.

Agora começa mais devagar, mas fica cada vez mais rápido e termina mais cedo do que antes. Portanto, parece "resolver" o problema ou, pelo menos, ter um efeito positivo.


1

Se você alternar para um USB 3.0, passará de 1mb / s para um woping de 5-8mb / s. Eu mudo para um pci USB 3.0 e HD externo e não olhei para trás.


1

Quando você olha em / etc / mtab, vê que o dispositivo foi montado com a opção "flush"?

Nesse caso, isso pode ser a causa do problema (foi para mim). Apenas desmonte o dispositivo e remonte-o, pois não deve ser definido por padrão.


A opção de descarga é definida por padrão, alguma maneira de parar isso?
— Ben Lutgens

@ Ben Lutgens - Sim, você pode colocar sua própria entrada no / etc / fstab que não possui as opções de liberação. Use sudo blkid para encontrar o UUID do dispositivo relevante e coloque uma entrada como UUID = "seu dispositivo uuid aqui" / mnt / <seu ponto de montagem aqui> uid = 1000, gid = 1000, fmask = 0022, dmask = 0022 0 0. Altere o uid, gid para corresponder ao ID do usuário e ao ID do grupo do usuário normal que você usa (conforme encontrado por getent passwd <seu usuário>).
— A.Danischewski

Quando faço isso, tudo o que muda é que não recebo mais barra de progresso para a cópia e a cópia parece realmente entrar / terminar quando tento desmontar o dispositivo e ele diz "não desconecte até que a operação esteja concluída "
— 21917 Jenny O'Reilly

0

Eu tive alguns problemas também com a taxa de transferência em um disco externo WD, depois de abri-lo no Windows SO, eu sempre usei o LINUX, depois a taxa de transferência era de 1,5 mb / s do que desmontava o disco rígido externo runed dmesg lá estava dizendo que o sdb1 foi desmontado de maneira inadequada, executou um fsck, que fez alguns reparos e, depois disso, 20mb / s de taxa de transferência novamente ao copiar do sda para o disco externo. O fsck é sempre um risco se você tiver dados, mas funcionou para mim, sem perda de dados.


-2

Eu também tive esse problema, mas uso o comando cp e você atualiza seu pendrive em segundos;

cp -r -u /home/user/Muziek/ /media/user/Audiousbsti
cp -r -u /home/user/Muziek/ /media/user/4F49-4A65/

Eu acho que é uma resposta muito tardia, mas ainda está aberta.


-3

Ok, eu tive o mesmo problema por três dias e como consegui fazer backup do meu disco rígido de 1 TB usando rsync, eu sei que ele é usado para fazer backup, mas conseguiu o trabalho, mesmo ao transferir arquivos grandes para uso faça esse trabalho. Se você quiser usá-lo com uma GUI, sugiro instalar o Grsync, que é uma versão gráfica do rsync, pois o rsync é executado no terminal.

Espero que isso tenha ajudado

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.