Diagnosticando "Input/output error"

2026-06-06 Tempo de leitura: Cerca de 11 min Dificuldade: Intermediário

O que "Input/output error" realmente significa?

Conclusão: Input/output error é o EIO (errno 5) do kernel. Não é um erro de lógica - significa que um I/O falhou na camada física: disco com defeito, cabo/controlador instável, dispositivo desconectado ou queda de armazenamento de rede.

Uma falha típica 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 (permissões) ou No space left (capacidade), Input/output error significa que o comando estava correto mas uma camada inferior não conseguiu responder. A causa está fora da sua aplicação - no lado do dispositivo.

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

• A. O próprio disco está falhando (mais comum) - setores defeituosos, desgaste, falhas SMART. Frequentemente apenas arquivos específicos retornam EIO
• B. Problema de conexão / 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 está inativo ou com timeout
• E. Corrupção severa de filesystem - metadados danificados rejeitam leituras e escritas

O que devo verificar primeiro?

Conclusão: A fonte primária é 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 é uma falha que o kernel recebeu de um driver de dispositivo e repassou. A evidência está 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 número de sector confirma A (disco com defeito). Linhas empilhadas de link down / reset apontam para B (conexão). Um disconnect é C. Isso decide todos os passos seguintes.

Como confirmo um disco com defeito? (SMART)

Conclusão: Se o dmesg mostra medium error / sector, leia os autodiagnósticos do disco com smartctl. Um Reallocated_Sector_Ct ou Current_Pending_Sector crescente significa desgaste físico - faça 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 está se desgastando. Trate como fim de vida: resgate os dados e substitua.
• Apenas UDMA_CRC_Error_Count está alto -> provavelmente um problema de cabo/conexão (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 corrupção de filesystem?

Conclusão: Se o dmesg mostra EXT4-fs error (ou similar) mas o SMART está saudável, repare os metadados com fsck - mas apenas enquanto o filesystem estiver desmontado. Executar em um FS montado piora a corrupção.

Primeiro inspecione somente leitura (-n não 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 (/) é o alvo e não 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 já foram resgatados:

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

Quando não é o disco

Conclusão: Se o dmesg mostra link down / disconnect / nfs ... not responding, a causa é conexão, desconexão ou rede - não a superficie do disco. Verificações físicas ou remontagem geralmente resolvem; não é necessário fsck.

Conexão / 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 alimentação própria ou adaptador AC
• Monitore o dmesg ao vivo para ver se melhora (dmesg -w)

Desconexão de dispositivo (C)

Em USB disconnect, /dev/sdX desaparece e toda operação 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 está morta. Desmonte, reconecte e remonte.

Armazenamento de rede (D)

Uma queda de servidor NFS ou falha de rede também 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 também Corrigindo "Stale file handle" no NFS. Stale file handle (ESTALE) é fácil de confundir com EIO mas precisa de uma correção diferente.

Como resgatar dados em emergência?

Conclusão: Extraia dados de um disco morrendo com ddrescue, não com cp simples. Ele pega os blocos legíveis primeiro e pula os defeituosos, para que você recupere o máximo possível 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 áreas 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 (lê setores reais, ignorando o cache do SO)
• -r3 - tenta blocos defeituosos até 3 vezes
• rescue.map - mapa de progresso; re-execute o mesmo comando para retomar de onde parou

Copie a imagem do dispositivo/partição inteiro para o destino, depois execute fsck ou recuperação de arquivos contra a cópia. O objetivo é minimizar operações contra o disco morrendo em si.