Estou usando f3
um script Bash personalizado para testar a memória flash USB em grandes quantidades.
Um problema comum que encontro é que algumas unidades defeituosas fariam com que todas as unidades saudáveis ficassem sem IO, efetivamente parando o processo de teste.
Por exemplo - ao deixar 50 unidades USB para teste, geralmente descubro depois de uma hora que 48 não estão fazendo nada e 2 estão piscando seus LEDs. A remoção dessas duas unidades de repente retoma o teste de todas as outras unidades.
Às vezes, há situações mais complexas em que 24 unidades estão paradas e o restante parece funcionar bem. Exceto que algumas unidades não fazem nenhum progresso após 20 minutos. Você os conecta, o resto está voltando à vida e o teste continua.
No entanto - eu também descobri que é suficiente parar de testar as unidades defeituosas para fazer o resto ganhar vida.
Estou procurando uma maneira de descobrir quais unidades estão causando esse bloqueio de operação de arquivo em outras pessoas para que eu possa interrompê-las automaticamente no meu script.
Estive assistindo atop
, iostat
, htop
e dmesg
tentando encontrar um fator de discriminação, mas não consigo ver nada. Descobri que existe a chamada usbmon
interface de depuração do kernel, embora seja tão de baixo nível que eu realmente não saiba como usá-la. Os pacotes USB brutos não me dizem nada.
Existem outras ferramentas que eu poderia usar para saber quais unidades estão se comportando mal?
Eu uso f3write
e f3read
programas para testar as unidades. O f3write
programa cria arquivos de 1 GB que o f3read
programa lê identificando qualquer dano de dados ocorrido no processo.
Além disso - é estranho, mas quando uma unidade com mau comportamento está presente, o restante das unidades "saudáveis" terminará seu trabalho no arquivo atual. Diga - escrever ou ler um arquivo de 1 GB - mas não criará um novo arquivo até que as unidades com mau comportamento sejam removidas. É como abrir um novo arquivo se tornasse impossível na presença de uma unidade "IO hog".
O que posso fazer para diferenciá-los?
Finalmente encontrei uma maneira de fazer isso.
Aqui está um script Bash que listará as unidades com sua taxa de E/S de leitura/gravação somada a cada segundo. Se uma unidade ou várias unidades estão deixando outras pessoas sem IO - elas podem ser identificadas como as que têm os números mais altos aqui:
O script usa arquivos /sys/block/sd*/stat para exibir E/S/s para cada dispositivo de bloco presente no sistema. Eu não tenho certeza de que unidades são essas, mas se maldita funciona, e isso é tudo que me importa.
Este foi um verdadeiro pesadelo. Teste de imagem de 40 unidades com f3 usando 4 hubs USB. Então tudo pára e você não sabe por quê. Se as unidades tiverem LEDs, geralmente os que deixam o resto de IO estão piscando enquanto o resto não - mas muitos módulos de memória flash não têm isso. Portanto, antes de encontrar isso, não havia como descobrir o que causa o problema.
Observe que isso não é o que relata como taxa de leitura/gravação da unidade - essas leituras são incorretas para essas unidades com mau comportamento. Muitas vezes, todas as leituras estarão em zero, mas usando o script acima você pode distinguir os porcos desagradáveis e removê-los para que o resto possa continuar.
Finalmente!
Aqui está a saída típica indicando um problema:
E aqui está como uma situação relativamente saudável se parece:
Quanto mais uniforme a distribuição - melhor. Talvez calcular o valor médio também ajude. A diferença entre o máximo e a média provavelmente pode indicar um problema.
Observe que as capturas de tela não mostram sda, pois as tirei de uma versão diferente do script que listou apenas as unidades nas quais minha ferramenta de teste em massa opera.