Como obtenho melhores velocidades de transferência USB no (X) ubuntu?

Question

Quando eu conecto minha unidade USB 2.0 ao Xubuntu e tento transferir arquivos grandes, as velocidades de transferência são boas no começo, mas caem após alguns segundos para 1-2 Mib / s. Pelo que eu li, a transferência rápida no início é apenas até o cache ficar cheio, então a velocidade de transferência real do USB é usada.

No Windows, a velocidade é constante em cerca de 25Mib / s, mesmo pau, conectado à mesma porta.

Esta é a saída do dmesg ao conectar o stick:

[ 5237.580084] usb 1-4: new high speed USB device using ehci_hcd and address 6
[ 5237.714318] scsi4 : usb-storage 1-4:1.0
[ 5238.713909] scsi 4:0:0:0: Direct-Access     SanDisk  Cruzer           8.02 PQ: 0 ANSI: 0 CCS
[ 5238.715264] sd 4:0:0:0: Attached scsi generic sg2 type 0
[ 5238.727225] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[ 5242.308981] sd 4:0:0:0: [sdb] 31301631 512-byte logical blocks: (16.0 GB/14.9 GiB)
[ 5242.309589] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 5242.311228] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 5242.311238]  sdb: sdb1

O bastão é montado automáticamente, aqui está a saída de "mount":

/dev/sdb1 on /media/B82C-6B07 type vfat (rw,nosuid,nodev,uhelper=udisks,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush)

Eu tenho que usar vfat porque eu quero transferir arquivos para o meu sistema Playstation3. Embora o teste abaixo mostre que esta não é a causa principal.

Parece que este é um problema comum no (X) ubuntu. Ainda não encontrei uma solução clara. Parece que o stick precisa ser montado como async em vez de flush, mas não sei exatamente como conseguir isso. Eu não me importo se eu tiver que desmontar o stick cada vez antes de desconectá-lo, desde que as velocidades de transferência sejam melhores.

Alguma idéia?

2 de novembro: Este relatório de bug parece estar relacionado: link . O que me preocupa é que o problema parece ter mais de 2 anos e ainda não está resolvido.

10 de novembro: Eu iniciei um teste de leitura com o palimpstest (do projeto gnome-disk-utility). Isso me dá uma taxa de transferência mínima de 23 MBit / s. Também tentei no krusader agora, a velocidade de leitura é constantemente > 20 MBit / s. Então o problema é apenas escrever para o pau!

Aqui está uma imagem de um teste de leitura / gravação no mesmo programa:

Eutivequedeletarcompletamenteosistemadearquivosantesdoteste,oquemostraqueovfatnãoéacausaprincipal,comomencionadoacima.

Outradica:seeutransferirumarquivode100MB,umavezem100%,levaumtempoincomumparaconcluiratransferência.Issonovamentemeparecequeoarquivoestádefatoemumcache,masgravarnodispositivousbémuitolento.

12denovembro:"Boas notícias". Os problemas parecem ser o próprio memory stick. Tentar um disco rígido externo (My Book Elite 1TB) me dá uma velocidade de gravação constante de cerca de 20 MiB / s. Primeiro eu tentei reformatar meu memory stick para poder comparar os dois (os sistemas de arquivos eram diferentes). Após a reformatação, as duas unidades são montadas exatamente da mesma maneira:

/dev/sdb1 on /media/My Book type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)
/dev/sdc1 on /media/cruzer_ type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)

Cruzer é o stick (a velocidade ainda diminui após alguns segundos), My Book é o disco rígido externo com uma velocidade de gravação constante de 20 MiB / s.

Difícil dizer qual é o problema então. Como eu disse, no Windows também obtenho velocidades de gravação igualmente rápidas com o SanCruzer.

Editar no final da recompensa: Infelizmente, o problema com o bastão ainda não está resolvido. No entanto, depois de 7 dias eu quero premiar a recompensa, é claro. O comentário de aking1012 foi muito útil, pois lançou uma nova luz sobre o assunto. No entanto, eu sinto que tenho que dar a recompensa para harrymc como ele mostrou o maior esforço de obter o problema resolvido. Obrigado a todos.

    

Answer 1

O artigo Taxa lenta de transferência de stoarage em massa USB 2.0 sugere que isso pode ser um problema do dispositivo ser montado por padrão com o opção de sincronização:

Do you have a "Devices" Icon on your Desktop?
If so, open it. If not, try opening media:/ in konqueror.

Selct the device then -> Properties -> Mounting(tag) and uncheck the Synchronous box. (This gets remembered, so you should only need to do it once per-device).

Mais algumas ideias vêm do relatório de erros Escreva através de um disco rígido externo fazendo a gravação muito lenta

• you change to async at runtime by 'sudo mount -o remount,async /dev/sda1' (or whatever your mounted partition(s) is/are)
• you create an fstab entry for sda which mounts it async (this requires that the device is always plugged in at boottime)
• you change 'sync' to 'async' in the pmount source and rebuild the package

Veja também a discussão no artigo em relação ao pmount, se isso se aplicar ao seu sistema.

Outra solução mágica vem de Gravação lenta USB 2.0, mas rápida de ler, solução ainda? e envolve re-montagem:

When I mount a USB drive on /dev/sdc1 with the following line

/dev/sdc1       /mnt/sdc1     auto    sync,noauto,user,exec     0       0

in /etc/fstab, and try to copy a 5.2 MB file to the drive from the local hard disk, then after an entire minute, 244 KB have been transferred. Copying a 29 MB file from the external drive to the local drive takes about 10 seconds.

Then if I unmount it, change the line in /etc/fstab to

/dev/sdc1       /mnt/sdc1     auto    noauto,user,exec     0       0

then copying the 29 MB file to the external disk takes an unnoticeable fraction of a second. Same with copying to the local disk from the external disk.

Veja este artigo e a referência a "usbtree". Ele informa como verificar se o usb está funcionando como 1.1 ou 2.0:

Linux e USB 2.0 .

    

Answer 2

O acesso à unidade é geralmente armazenado em buffer no modo assíncrono. O estouro rápido inicial é provável para o cache de memória. Velocidade lenta é a velocidade real de gravação.

Se você tiver um pen drive que pisca durante a transferência, tente alguns testes. Eu achei que as gravações podem continuar por um bom tempo depois que a cópia for concluída.

A montagem no modo assíncrono, em vez do modo de sincronização, permite que a cópia pareça prosseguir mais rapidamente, mas não oferece a mesma segurança de que os dados copiados são realmente transferidos.

Verifique as opções em man mount . Alguns formatos permitem que as atualizações de metadados (diretório, tabela de alocação de arquivos, etc) sejam adiadas. Isso reduzirá a quantidade de dados que precisam ser copiados. Isso aumenta um pouco o risco de perda de dados.

    

Answer 3

Então cheguei a esta página por meio de uma pesquisa no google sobre o mesmo problema ("ubuntu 15 speed up usb transfer") porque minhas transferências estavam sendo executadas a 75kb / s.

Esta foi provavelmente apenas a solução para a minha configuração, mas o meu drive USB de 16GB foi formatado para GPT fat32, eu apaguei todas as partições, inicializei para o MBR, fiz uma única partição NTFS, conectei de volta ao meu PC Ubuntu e agora está transferindo um arquivo de 10 GB com mais de 50 MB / s. Para mim, problema resolvido.

    

Answer 4

Precisamos ter certeza de que o sistema tente escrever em blocos de blocos de programa / apagar. Com memória flash moderna, eles geralmente têm tamanho de 1M a 4M. Para fazer isso, você quer ter certeza de que o seu FS está alinhado para apagar os blocos, e essa interface permite a transferência inteira do bloco de uma só vez (para bastões baratos). Caso contrário, obteríamos amplificação de gravação, já que o sistema tenta escrever em blocos menores, do que apagar bloco (ler / modificar / gravar) + desalinhamento de bloco.

Para verificar sua configuração atual, faça o seguinte:

cat /sys/block/sd**X**/device/max_sectors

Você pode ajustar as regras do salão para esses dispositivos. Consulte link .

Nesse caso, eu havia substituído max_sectors para todos os dispositivos, que usavam o padrão de 240 (armazenamento USB) para setores de 32K ou setores de 2K:

(use == para verificar e = para atribuir):

No meu sistema (Mageia 4, 3.14.24 core i7) eu tive que fazer isso devido a velocidades de gravação terrivelmente baixas (2MB / seg) no Kingston DT101 G2 16GB:

vi /usr/lib/udev/rules.d/81-udisks_maxsect.rules e adicione:

SUBSYSTEMS == "scsi", ATTR {max_sectors} == "240", ATTR {max_sectors}="32678"

E a velocidade de escrita dd subiu 3x vezes :-) mc cp provavelmente 10-20x para cima (depois de eu ter começado o primeiro setor da partição @ 8192'e reformatado com 64k clusters alinhados):

fdisk -u /dev/sdh (torne o DOS compatível se ativado),

mkfs.vfat /dev/sdh1 -n KINGSTON16G -s 128 **-R 4592** e use fsck.vfat -v /dev/sdh1 para verificar o alinhamento (verifique [data start sector] deve ser múltiplo de 128 (tamanho do cluster)). Ajuste o número dos setores reservados (-R), se necessário.

Os max_sectors padrão (240) parecem causar alta amplificação de gravação em algumas das novas unidades baratas. Mas tenha muito cuidado com essa configuração alta, o efeito similar é alcançado em 2048 setores (provavelmente 1M apaga blocos:

SUBSISTEMS == "scsi", ATTR {max_sectors} == "240", ATTR {max_sectors}="2048"

Teste todos os seus dispositivos USB antigos, que eles ainda funcionam bem. Use atributos de fornecedor / modelo nos arquivos de regras para serem mais específicos.

PS: Se estiver usando o ext3 / 4:

Desative o registro em diário e defina stride / stripe_width para mkfs.ext3:

mkfs.ext3 -O ^ has_journal -E stride = [ler blocos fs da página] -E stripe-width = [apagar bloco blocos fs]

    

Answer 5

Eu tive alguns problemas também com taxa de transferência em um disco externo WD, depois de abri-lo em um windows SO, sempre usei LINUX, depois disso a taxa de transferência era de 1.5mb / s do que desmontava o disco rígido externo, rodava dmesg lá estava dizendo que sdb1 era desmontado unporperly, correu um fsck, que fez alguns reparos e depois que 20mb / s de taxa de transferência novamente quando copia de sda para disco externo.
"O fsck é sempre um risco se você tiver dados, mas funcionou para mim, sem perda de dados"