Por que meu PC está congelando enquanto copio um arquivo para um pendrive?

Eu tenho uma situação realmente estranha aqui. Meu PC funciona bem, pelo menos na maioria dos casos, mas há uma coisa com a qual não consigo lidar. Quando tento copiar um arquivo do meu pendrive, tudo está bem - eu tenho 16-19M / s, funciona muito bem. Mas quando tento copiar algo para o mesmo pendrive, meu PC congela. O ponteiro do mouse para de se mover por um segundo ou dois, depois se move um pouco e para novamente. Quando algo está tocando, por exemplo, no Amarok, o som age como uma metralhadora. A velocidade salta de 500K / sa 15M / s, em média 8M / s. Isso ocorre apenas quando estou copiando algo para um pendrive. Quando o processo de cópia é concluído, tudo volta ao normal.

Eu tentei de tudo - outro pendrive, uma porta USB diferente no painel frontal ou as portas de trás, até mudei os pinos USB na placa-mãe (painel frontal), mas não importa onde eu coloquei meu pendrive, é sempre o mesmo. Tentei sistema de arquivos diferente - fat32, ext4. Não tenho nenhum problema com o dispositivo no Windows, no meu laptop. Tem que ser o meu PC ou algo no meu sistema. Não tenho ideia do que procurar. Estou usando o teste Debian com o Openbox autônomo. Meu PC é meio antigo - Pentium D 3GHz, 1GiB de RAM, disco WD Green de 1,5TB. Se você tem algo que me ajudaria a resolver esse problema, ficaria feliz em ouvir isso.

Não sei que outras informações devo fornecer, mas se você precisar de algo, basta perguntar, atualizarei esta postagem o mais rápido possível.

Eu tentei reproduzir este problema no ubuntu 13.04 live cd. Montei minha partição criptografada + troca criptografada e conectei meu pendrive a uma porta USB. Em seguida, tentei iniciar alguns aplicativos e agora tenho ~ 820MiB na RAM e cerca de 400MiB no SWAP. Não há problema em copiar, nem congelar, tudo está como deveria ser. Então, parece que é uma falha do sistema, mas onde exatamente? O que causaria um comportamento tão estranho?

Você está usando uma versão de 64 bits do Linux com muita memória? Nesse caso, o problema pode ser que o Linux possa travar por minutos em grandes gravações em dispositivos lentos, como, por exemplo, cartões SD ou pen drives. É um bug conhecido que deve ser corrigido nos kernels mais recentes.

Veja http://lwn.net/Articles/572911/

Solução alternativa: como problema raiz:

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

Eu o adicionei ao meu /etc/rc.localarquivo em minhas máquinas de 64 bits.

TANSTAAFL ; essa alteração pode (e provavelmente reduzirá) sua taxa de transferência para esses dispositivos - é um compromisso entre latência e velocidade. Para voltar ao comportamento anterior, você pode

echo 0 > /proc/sys/vm/dirty_background_bytes
echo 0 > /proc/sys/vm/dirty_bytes

... quais são os valores padrão, o que significa que o comportamento de write-back será controlado pelos parâmetros dirty_ratioe dirty_background_ratio.

Nota para o pessoal não tão especialista com linux: os arquivos /proc são pseudofiles --- apenas canais de comunicação entre o kernel e o espaço do usuário. Nunca use um editor para alterar ou olhar para eles; obtenha um prompt de shell --- por exemplo, com sudo -i(sabores do Ubuntu) ou su rootuse echoe cat).

Atualização 2016/04/18 parece que, afinal, o problema ainda está aqui. Você pode vê-lo no LWN.net , neste artigo sobre filas de write-back .

O motivo pode ser a amplificação de gravação, pois o sistema tenta gravar em blocos menores do que apagar o bloco (executando leitura / modificação / gravação) + desalinhamento do bloco.

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

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

Você pode ajustar as regras do salão para esses dispositivos:

Altere o valor de "max_sectors" USB para uma família inteira de dispositivos

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

No meu sistema (Mageia 4, 3.14.24 core i7), eu tive que fazer isso devido a velocidades de gravação terrivelmente lentas (2 MB / s) na 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 ddvelocidade de gravação aumentou 3x vezes. mc cpprovavelmente 10-20x (depois que eu iniciei a primeira partição no setor 8192'th e reformatei com clusters alinhados de 64k):

fdisk -u /dev/sdh # make DOS compat off if on
mkfs.vfat /dev/sdh1 -n KINGSTON16G -s 128 **-R 4592*** and use *fsck.vfat -v /dev/sdh1

para verificar o alinhamento (marque [setor de início de dados] deve ser múltiplo de 128 (tamanho do cluster)). Ajuste o número de setores reservados (-R), se necessário.

O max_sectors padrão (240) parece causar alta amplificação de gravação em algumas das novas unidades baratas. Mas tenha muito cuidado com essa configuração alta, o efeito semelhante é alcançado em 2048 setores (provavelmente 1 milhão de blocos de apagamento:

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

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

hardware x software

Eu encontrei um problema estranho semelhante a este com os pendrives USB e, na minha pesquisa, quase sempre é um problema de driver ou o hardware específico do PC / Placa-Mãe.

Eu sei disso porque tenho vários sistemas que são hardware idêntico e, em um, posso fazer essa operação sem problemas, enquanto em outro o problema aparece.

O que fazer?

Suas opções são realmente limitadas aqui. As únicas coisas que você pode fazer são garantir que você tenha o BIOS / firmware mais recente instalado no sistema e as versões mais recentes dos pacotes deste.

Além disso, tudo o que posso sugerir é garantir que você evite essa situação, não tentando copiar arquivos enquanto outra cópia estiver em andamento.

Se você tem o tipo de personalidade em que coisas como essa o incomodam, tente outra distribuição ao vivo do Linux e repita as etapas que levam ao seu problema. Isso eliminaria apenas se é um problema específico da distribuição ou um problema de hardware, como descrevi acima. Seria um pequeno consolo, mas eu sempre gosto de saber as coisas, em vez de enterrar a cabeça na areia, e não.

Algo mais?

Se você é realmente obsessivo, tente executar o aplicativo com o qual está fazendo a cópia, stracena esperança de capturar o sistema em qualquer chamada que esteja congelando. Você deve conseguir fazer isso também na linha de comando.

Exemplo

$ strace -o cp1.log cp -r /path/to/dir1 /path/to/usb/. 

Então, enquanto estiver executando, inicie outro.

$ strace -o cp2.log cp -r /path/to/dir2 /path/to/usb/. 

Espera-se que o sistema congele durante esta operação e talvez você tenha sorte e encontre fumaça nesses arquivos de log.