Diagnosticando "Input/output error"

Diagnosticando "Input/output error"

O que "Input/output error" realmente significa?

Conclusao: Input/output error e o EIO (errno 5) do kernel. Nao e um erro de logica - significa que um I/O falhou na camada fisica: disco com defeito, cabo/controlador instavel, dispositivo desconectado ou queda de armazenamento de rede.

Uma falha tipica se parece com isto:

$ cat /var/log/app.log
cat: /var/log/app.log: Input/output error

$ cp bigfile /mnt/data/
cp: error reading 'bigfile': Input/output error

Diferente de Permission denied (permissoes) ou No space left (capacidade), Input/output error significa que o comando estava correto mas uma camada inferior nao conseguiu responder. A causa esta fora da sua aplicacao - no lado do dispositivo.

As causas se dividem em alguns grupos. Faca a triagem nesta ordem:

  • A. O proprio disco esta falhando (mais comum) - setores defeituosos, desgaste, falhas SMART. Frequentemente apenas arquivos especificos retornam EIO
  • B. Problema de conexao / controlador - cabo SATA/USB solto, energia insuficiente ou falha de HBA interrompe I/O intermitentemente
  • C. O dispositivo foi desconectado - um drive USB/externo foi desconectado, /dev/sdX desapareceu
  • D. Queda de armazenamento de rede - servidor NFS/iSCSI esta inativo ou com timeout
  • E. Corrupcao severa de filesystem - metadados danificados rejeitam leituras e escritas

Input/output error e um sintoma, nao uma causa. A mesma mensagem cobre um disco morrendo que voce precisa resgatar e uma falha transitoria que um cabo recolocado corrige. Partir para fsck ou reformatacao antes de ler o dmesg pode destruir dados que ainda estao vivos. Leia a causa primeiro.

O que devo verificar primeiro?

Conclusao: A fonte primaria e o log do kernel. Use dmesg -T ou journalctl -k para ler o nome do dispositivo (sda, etc.) e o erro exato (I/O error, sector, link reset) do momento em que o EIO apareceu. Isso quase sempre restringe a uma das causas A-E.

Escute o kernel com dmesg / journalctl

EIO e uma falha que o kernel recebeu de um driver de dispositivo e repassou. A evidencia esta sempre no log do kernel.

# Erros recentes, com timestamps
dmesg -T | grep -iE 'error|i/o|fail|reset' | tail -30

# Do log persistente (sobrevive a reboots)
journalctl -k -b -p err --no-pager

Como ler as linhas:

# A: disco com defeito (setor defeituoso)
blk_update_request: I/O error, dev sda, sector 1234567 op 0x0:(READ)
critical medium error, dev sda, sector 1234567

# B: problema de conexao / link
ata1: SATA link down (SStatus 0 SControl 300)
ata1.00: failed command: READ FPDMA QUEUED

# C: desconexao de dispositivo (desconexao USB, etc.)
sd 6:0:0:0: [sdb] Synchronize Cache(10) failed
usb 1-1: USB disconnect, device number 5

# D: queda de NFS
nfs: server 10.0.0.5 not responding, still trying

# E: corrupcao de filesystem
EXT4-fs error (device sda1): ext4_find_entry: reading directory lblock

Um medium error com um numero de sector confirma A (disco com defeito). Linhas empilhadas de link down / reset apontam para B (conexao). Um disconnect e C. Isso decide todos os passos seguintes.

Capture o log antes de tocar no arquivo ou dispositivo novamente. Um disco morrendo pode degradar a cada releitura. "So dar mais um cat" e o pior movimento.

Como confirmo um disco com defeito? (SMART)

Conclusao: Se o dmesg mostra medium error / sector, leia os autodiagnosticos do disco com smartctl. Um Reallocated_Sector_Ct ou Current_Pending_Sector crescente significa desgaste fisico - faca backup e substitua urgentemente.

Leia os dados SMART com smartctl do smartmontools (instale com apt install smartmontools / dnf install smartmontools).

# Resumo de saude
sudo smartctl -H /dev/sda

# Todos os atributos
sudo smartctl -a /dev/sda

Atributos que importam:

ID# ATTRIBUTE_NAME          RAW_VALUE
  5 Reallocated_Sector_Ct   48      <- setores defeituosos realocados. crescente = desgaste
197 Current_Pending_Sector  16      <- setores suspeitos aguardando realocacao; causa direta do EIO
198 Offline_Uncorrectable   16      <- setores irrecuperaveis
199 UDMA_CRC_Error_Count    120     <- origem no cabo/conexao (o disco em si pode estar bem)
  • Current_Pending_Sector / Reallocated_Sector_Ct diferente de zero e crescente -> o disco esta se desgastando. Trate como fim de vida: resgate os dados e substitua.
  • Apenas UDMA_CRC_Error_Count esta alto -> provavelmente um problema de cabo/conexao (B); recolocar ou substituir o cabo pode resolver.

Confirme com um self-test curto:

sudo smartctl -t short /dev/sda     # verifique resultados com -a alguns minutos depois

E corrupcao de filesystem?

Conclusao: Se o dmesg mostra EXT4-fs error (ou similar) mas o SMART esta saudavel, repare os metadados com fsck - mas apenas enquanto o filesystem estiver desmontado. Executar em um FS montado piora a corrupcao.

Primeiro inspecione somente leitura (-n nao escreve nada):

# Identifique o alvo e seu estado de montagem
lsblk -f
findmnt /mnt/data

# Desmonte, depois verifique (-n = dry run somente leitura)
sudo umount /dev/sda1
sudo fsck -n /dev/sda1

Se o filesystem raiz (/) e o alvo e nao pode ser desmontado, execute fsck no boot ou de um live USB / modo de resgate.

# Forcar fsck no proximo boot (para o FS raiz)
sudo touch /forcefsck      # no systemd, o argumento de kernel fsck.mode=force e mais confiavel

Uma vez confirmado, repare de verdade - assumindo que dados importantes ja foram resgatados:

sudo fsck -y /dev/sda1     # -y = aprovar reparos automaticamente

Nunca execute fsck em um filesystem montado. O kernel e a ferramenta reescrevem os mesmos metadados independentemente e transformam danos menores em uma bagunca fatal. Se voce nao consegue umount (device is busy), veja Corrigindo "device is busy" no umount.

Quando nao e o disco

Conclusao: Se o dmesg mostra link down / disconnect / nfs ... not responding, a causa e conexao, desconexao ou rede - nao a superficie do disco. Verificacoes fisicas ou remontagem geralmente resolvem; nao e necessario fsck.

Conexao / cabo (B)

UDMA_CRC_Error alto, linhas empilhadas de SATA link down / ata reset:

  • Recoloque o cabo SATA/USB; tente uma porta ou cabo diferente
  • Drives externos frequentemente falham por energia insuficiente - use um hub USB com alimentacao propria ou adaptador AC
  • Monitore o dmesg ao vivo para ver se melhora (dmesg -w)

Desconexao de dispositivo (C)

Em USB disconnect, /dev/sdX desaparece e toda operacao posterior retorna EIO.

lsblk                       # o dispositivo esta visivel?
sudo dmesg -w               # observe o momento em que voce reconecta

Uma montagem em um dispositivo que desapareceu esta morta. Desmonte, reconecte e remonte.

Armazenamento de rede (D)

Uma queda de servidor NFS ou falha de rede tambem aparece como EIO. Verifique o servidor e o caminho.

mount | grep nfs
ping <nfs-server>
showmount -e <nfs-server>    # as exportacoes estao visiveis?

Para uma montagem NFS travada, leia tambem Corrigindo "Stale file handle" no NFS. Stale file handle (ESTALE) e facil de confundir com EIO mas precisa de uma correcao diferente.

Como resgatar dados em emergencia?

Conclusao: Extraia dados de um disco morrendo com ddrescue, nao com cp simples. Ele pega os blocos legiveis primeiro e pula os defeituosos, para que voce recupere o maximo possivel antes do disco pifar.

cp trava em EIO e martela o disco novamente em cada tentativa. ddrescue (do gddrescue; apt install gddrescue, nome do comando ddrescue) pula areas defeituosas e pode retomar de um arquivo de mapa.

# /dev/sdb (disco com defeito) -> /dev/sdc (destino saudavel)
# o terceiro argumento e um arquivo de mapa que permite pausar e retomar
sudo ddrescue -d -r3 /dev/sdb /dev/sdc rescue.map
  • -d - I/O direto (le setores reais, ignorando o cache do SO)
  • -r3 - tenta blocos defeituosos ate 3 vezes
  • rescue.map - mapa de progresso; re-execute o mesmo comando para retomar de onde parou

Copie a imagem do dispositivo/particao inteiro para o destino, depois execute fsck ou recuperacao de arquivos contra a copia. O objetivo e minimizar operacoes contra o disco morrendo em si.

Caminho rapido: (1) dmesg -T \| grep -i error para classificar a causa (A-E) -> (2) em medium error, confirme desgaste com smartctl -a -> (3) se desgastado, ddrescue imediatamente -> (4) para corrupcao de FS, fsck apos resgate (desmontado) -> (5) para link/desconexao/NFS, verifique o caminho fisico. Pular o dmesg e o unico erro a evitar.

Resumo / Proximas Leituras