Estou tendo uma série de cartões SD com falha / às vezes com falha. Eles fornecem uma das seguintes dmesgsaídas:
Os completamente mortos (não liste em /dev/mmcblk0):
[ +0,000010] mmc0: error -110 whilst initializing SD card
[ +2,819983] mmc0: card never left busy state
Os com falha (ocasionalmente ainda podem ser montados):
[Jun16 06:28] mmc0: new high speed SDHC card at address 0001
[ +0,000339] mmcblk0: mmc0:0001 00000 3.68 GiB
[ +0,002835] mmcblk0: p1 p2 p3 p4
[ +10,256689] mmcblk0: timed out sending r/w cmd command, card status 0x900
[ +11,264358] mmcblk0: timed out sending r/w cmd command, card status 0x900
[ +0,000016] print_req_error: I/O error, dev mmcblk0, sector 7716736
[ +10,239972] mmcblk0: timed out sending r/w cmd command, card status 0x900
[ +0,000018] print_req_error: I/O error, dev mmcblk0, sector 7716736
[ +0,000008] Buffer I/O error on dev mmcblk0, logical block 964592, async page read
[ +10,239931] mmcblk0: timed out sending r/w cmd command, card status 0x900
[ +0,000009] print_req_error: I/O error, dev mmcblk0, sector 81792
[Jun16 06:29] mmcblk0: timed out sending r/w cmd command, card status 0x900
[ +0,000020] print_req_error: I/O error, dev mmcblk0, sector 1066880
[ +10,240219] mmcblk0: timed out sending r/w cmd command, card status 0x900
[ +0,000011] print_req_error: I/O error, dev mmcblk0, sector 2101120
O melhor que tenho error -110é que é uma espécie de tempo limite , mas diz muito pouco sobre o que realmente aconteceu com o SDCard.
Antecedentes de como isso aconteceu
Os cartões SD acabam nesses estados em alguns (aparentemente aleatórios) dispositivos incorporados em que estou trabalhando, e estou tentando entender se é uma questão de cartões SD ruins ou se pode haver algo errado com o driver do controlador que está empurrando as cartas para a corrupção.
Cerca de 5% dos cartões morreram completamente, e estou tentando ver se isso é o que esperar dos outros.
Tentei forçar o SDcard a reproduzir o problema, mas os que estão sendo testados (mesma marca, mesmo tipo de dispositivo com o mesmo software) não mostram nenhum vestígio de desgaste após centenas de GB de dados gravados neles de maneira contínua como parte do teste. Eu uso o stressdisk para isso.
Eu não tenho uma pista de quantas vezes o dispositivo pode ter perdido energia abruptamente, e a fonte de alimentação é um adaptador AC-DC 2A regular que está funcionando bem para todas as outras necessidades do dispositivo.
Atualizar
A questão parece ser sugerida para ser fechada ou respondida de maneira helps me prevent failed SD cards in the futurediferente de using Linux to diagnose what is the current state of the SDcards.
Deixe-me tentar reformular então:
Qual é a maneira mais completa de analisar uma falha de cartão SD no Linux?
- É possível habilitar logs de depuração para o subsistema MMC para obter mais informações?
- O que é um
card status 0x900? - É possível detectar a comunicação SD-bus ou SD-bus do espaço do usuário para obter indicações de que o cartão está começando a falhar?
Eu posso expandir o acima. Mas concordo com o primeiro ponto, e concordo que esta foi a primeira pergunta a ser feita.
A única confiança que tive ao atribuir falhas veio mais do "histórico" e dos resultados gerais que recebo, não dos erros específicos de comandos de baixo nível. Que provavelmente variam entre as implementações de qualquer maneira.
Mesmo com um SSD, de uma marca razoável, acredito que tive dados ruins retornados no lugar de erros de E/S. Esse certamente foi um dos modos de falha conhecidos em muitos SSDs. [ 2013 ][ 2017 ]. (Possivelmente surpreendente para pessoas familiarizadas com os sistemas de arquivos contemporâneos e implementações de banco de dados que muitas vezes esperam um conjunto mais gerenciável de modos de falha). Observe que os artigos que relaciono aqui focaram nos dados retornados; eles não fizeram mais distinção nos erros relatados, exceto pela distinção de unidade morta / setor defeituoso que você já mediu.
Minha falha no SSD estava em um laptop "recondicionado pelo vendedor", que já havia sido "consertado" uma vez e estava começando a mostrar falhas novamente - plausivelmente causando uma interrupção de energia na unidade, assim como nos documentos vinculados. Também pode ter falhado em fornecer níveis de tensão estáveis.
Um bom hardware com uma boa fonte de alimentação não tende a destruir um bom cartão SD - a menos que você esteja colocando muita carga nele. A carga de trabalho é uma variável muito importante
, que você não mencionou [originalmente]. Esses cartões de memória são hardwares relativamente pequenos, geralmente baratos, projetados para uso relativamente pouco exigente, armazenando arquivos de mídia (daí MMC, "MultiMediaCard"). Os particularmente mais baratos não serão necessariamente muito bons em "nivelamento de desgaste" (redistribuindo a carga de blocos lógicos de hotspot em um grande número de blocos físicos).Eu medi a carga de trabalho com um hack rápido, agendando um trabalho cron diário para executar o
tunefs -l /dev/mmcblk0p4 | grep writes >> /var/log/writes.log.Mas se deixarmos a carga de trabalho de lado, você estaria certo em considerar um possível problema do lado do controlador a partir das informações fornecidas até agora. Eu tive setores defeituosos repetidos em um cartão SD devido a gravações de um dispositivo de bolso, possivelmente quando a bateria estava fraca. Este era um cartão de uma marca. Os setores foram recuperáveis e continuo usando o mesmo cartão. Eu também tive algum tipo de falha de inicialização transitória neste cartão, acho que também estava associado a setores defeituosos (depois que passei pela falha de inicialização), mas posso estar me lembrando mal.
A impressão que tenho da sua pergunta [original] é que esta é uma operação de pequena escala e executar uma matriz de teste rigorosa com diferentes placas, controladores e cargas de trabalho seria um exagero.Após a carga de trabalho, a primeira variável que você controla é o cartão.
Escrevendo em 2018, há uma marca global que pode ser considerada "canônica" para cartões SD -
veja os resultados em: https://www.amazon.com/s/field-keywords=sd+card
- e esperamos que você tenha vários canais de varejo que podem ser considerados... pelo menos confiáveis o suficiente para fins de comparação. (Lembrando que vários varejistas online populares atuam como "marketplace" além de venderem seus próprios produtos).
O hardware oficial do Raspbery PI também pode ser aceitável. Ou seja, cartões SD, vendidos oficialmente para rodar Linux em um pequeno computador de placa, que foram relatados como funcionando bem. (Sendo uma carga de trabalho mais exigente do que arquivos de mídia).
Como um pincel amplo, se você receber um cartão que é mais rápido do que o estritamente necessário, também penso nisso como uma classificação de resistência potencialmente mais alta. (Dado que a classificação de velocidade tende a ser muito mais disponível do que a resistência).
Se você controlar / medir essas duas variáveis, poderá concentrar seus julgamentos no restante do hardware relevante.
Observe que, no caso mais geral, se você achar que um dispositivo foi mal escrito, você pode tentar eliminar esta falha:
Se você tem um bom hardware MMC nativo como você, pode usar o comando Linux
blkdiscardcomo uma maneira mais eficiente de testar o apagamento de todos os blocos do dispositivo, antes de "reformatá-lo". Mas a eficiência é a única vantagem, em comparação com o teste de erros ao substituir toda a unidade com zeros, ou seja,dd bs=1M if=/dev/zero of=/dev/mmcblk0. (Além de evitar qualquer necessidade de escrever os blocos apagados,blkdiscardtambém poderia, em teoria, fornecer um desempenho mais "como novo" depois e aumentar a resistência, dando ao dispositivo um pouco mais de liberdade).(Se esta for uma unidade SATA - há um comando "secure erase" dedicado para descartar todo o conteúdo da unidade lógica (consulte Recursos
man hdparm). No entanto, não conheço nenhum comando MMC equivalente. Alguns fornecedores de SSD aproveitaram esse comando para redefinir seus tabelas de mapeamento de bloco, como uma solução alternativa para sua falha ao recuperar o desempenho "como novo" com ablkdiscardsequência equivalente. Observe que este comando não testa necessariamente uma exclusão completa da unidade. Em alguns casos, ele apenas apagará uma chave de criptografia interna).Desde que você perguntou como eram meus erros
Meu cartão micro-SD SanDisk foi reproduzido novamente recentemente. Parece que os erros específicos abaixo foram devidos à conexão escamosa. Foi resolvido removendo e reinserindo o micro-SD no adaptador micro-SD para SD, depois de soprar supersticiosamente em todas as almofadas de metal.
No leitor do meu laptop Dell Latitude E5450 (
sdhci-pcidriver do kernel, versão do kernel Fedora Linux por volta da v4.17), ele estava falhando ao inicializar a placa. No meu SheevaPlug (mesmos detalhes de hardware e software que esta pergunta ), esta placa parece ter sido capaz de inicializar, mas mostrou erros de E/S. Talvez na Dell os tempos limite de tratamento de erros não estejam configurados corretamente.Dell:
Sheevaplug: