☰

Comportamento estranho do SSD no TinyCore. Erros de E/S com programas Java, nenhum com dd

tag-icon • tag-icon linux ssd java
Comportamento estranho do SSD no TinyCore. Erros de E/S com programas Java, nenhum com dd

Estou usando o pxelinux para implantar uma versão in-ram do TinyCore (Linux versão 4.19.10-tinycore). Ele está rodando em uma placa-mãe Z270-A com BIOS mais recente (a partir de hoje). O PXE é inicializado no modo legado.

Escrevi um aplicativo Java que implanta imagens SSD na rede, gravando-as usando RandomAccessFile. Tenho experimentado um comportamento estranho ao escrever, especificamente este:

print_req_error: I/O error, dev sda, sector 42319888
Buffer I/O error on dev sda, logical block 5289986, async page read
ata1: EH complete
ata1.00: Enabling discard_zeroes_data
ata1.00: exception Emask 0x0 SAct 0x40000 SErr 0x0 action 0x0
ata1.00: irq_stat 0x40000008
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/08:90:10:c0:85/00:00:02:00:00/40 tag 18 ncq dma 4096 in
         res 41/40:00:10:c0:85/00:00:02:00:00/40 Emask 0x409 (media error) <F>
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/133
sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
sd 0:0:0:0: [sda] tag#18 Sense Key : 0x3 [current] 
sd 0:0:0:0: [sda] tag#18 ASC=0x11 ASCQ=0x4 
sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x28 28 00 02 85 c0 10 00 00 08 00
print_req_error: I/O error, dev sda, sector 42319888
Buffer I/O error on dev sda, logical block 5289986, async page read
ata1: EH complete
ata1.00: Enabling discard_zeroes_data

Tentei desabilitar o NCQ usando libata.force=noncqmas sem sucesso.

O estranho é quenenhum desses erros ocorre ao limpar o dispositivo usando dd if=/dev/zero of=/dev/sda bs=1Me depois tentar gravar dados novamente com meu programa. Parece que preencher a unidade com zeros resolve o problema, mas isso leva muito tempo e não é benéfico para a saúde do dispositivo.

Por esse motivo específico, implementei o programa escrevendo a imagem de forma que, antes de escrever os dados reais, sejam escritos zeros para simular o comando acima. Mesmo assim, o erro ainda acontece.

smartctl -a /dev/sdanão apresenta sinais ruins. Já vi isso acontecer com vários dispositivos, como Silicon Power S55 e Micron 1100. Issoapenasacontece nesta configuração. Isso nunca aconteceu com uma versão instalada do Ubuntu 18.04 (executada a partir de um disco, não de memória RAM).

A memória RAM não está com defeito, testada com memtest. Todos os cabos estão bons, funcionando em um Corsair RM1000i.

Aqui está uma saída dedmesg. Não consigo encontrar uma maneira de consertar isso, estou perdido neste momento. Além disso, aqui estásmartctlsaída.

EDIT: Nem sempre acontece no mesmo setor. Às vezes acontece em um setor que funcionou bem no passado. Parece aleatório.

EDIT2: Meu programa abre /dev/sdacomo um arquivo e executa E/S nele (é assim que escrevo no disco)

Responder1

Parece que as mensagens eram de fato erros falsos. Mudei meu código Java, em vez de usar FileOutputStreamagora uso esta biblioteca útil:http://www.nicecode.eu/java-streams-for-direct-io/

Ele fornece acesso de E/S nativo a arquivos usando JNA e posso ativar o sinalizador O_DIRECT. Modifiquei a biblioteca, aumentando o buffer de BLOCK_SIZE (512 bytes) para 512 KB (512*1024). O tamanho do buffer deve ser múltiplo do tamanho do bloco, que para O_DIRECT deve ser 512 bytes. Dessa forma, as velocidades são razoáveis, comparáveis ​​à implementação não nativa do Java.

Não há mais erros, todos os dados são válidos (confirmados usando md5sum), nem para o SSD Silicon Power testado anteriormente nem para o novo Micron.

informação relacionada