「Input/output error」の対処 - ディスク・デバイス障害の兆候

2026-06-06 読了時間: 約11分難易度: 中級

「Input/output error」とは何のサインか？

結論: Input/output error はカーネルが返す EIO（errno 5）。論理的なミスではなく、ストレージやデバイスの 物理層で I/O が失敗した サイン。ディスク不良・ケーブル/コントローラ異常・デバイス切断・ネットワークストレージ障害のいずれかを疑う。

ファイル操作中に次のように出る典型。

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

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

Permission denied（権限）や No space left（容量）と違い、Input/output error は 正しく操作したのに低レイヤーが応えられなかった ことを意味する。原因はアプリやコマンドの外、つまりデバイス側にある。

主な発生源は次の系統。切り分けの優先順位もこの順。

A. ディスク自体の不良（最頻）— 不良セクタ・寿命・SMART 異常。特定ファイルだけ EIO になることが多い
B. 接続・コントローラの問題 — SATA/USB ケーブル緩み・電源不足・HBA 異常で一時的に I/O が落ちる
C. デバイスの切断 — USB/外付けドライブが抜けた、/dev/sdX が消えた
D. ネットワークストレージの障害 — NFS/iSCSI のサーバ断・タイムアウト
E. ファイルシステムの深刻な破損 — メタデータ損傷で読み書きが弾かれる

Input/output error は 症状であって原因ではない。同じメッセージでも、退避すべき瀕死のディスクと、ケーブルを挿し直せば直る一過性障害がある。次節の dmesg を見ずに fsck や再フォーマットに走ると、生きているデータを失う。まず原因を読むこと。

まず何を確認すべきか？

結論: 一次情報は カーネルログ。dmesg -T または journalctl -k で、EIO が出た瞬間のデバイス名（sda 等）と具体的なエラー（I/O error, sector, link reset 等）を読む。これで A〜E のどれかがほぼ決まる。

dmesg / journalctl でカーネルの声を聞く

EIO はカーネルがデバイスドライバから受け取った失敗を上位へ返したもの。だから根拠はカーネルログに必ず残る。

# 直近のエラーを時刻付きで
dmesg -T | grep -iE 'error|i/o|fail|reset' | tail -30

# 永続ログから（再起動をまたいで追える）
journalctl -k -b -p err --no-pager

ログの読み分けの目安。

# A: ディスク不良（不良セクタ）
blk_update_request: I/O error, dev sda, sector 1234567 op 0x0:(READ)
critical medium error, dev sda, sector 1234567

# B: 接続/リンクの問題
ata1: SATA link down (SStatus 0 SControl 300)
ata1.00: failed command: READ FPDMA QUEUED

# C: デバイス切断（USB 抜け等）
sd 6:0:0:0: [sdb] Synchronize Cache(10) failed
usb 1-1: USB disconnect, device number 5

# D: NFS の障害
nfs: server 10.0.0.5 not responding, still trying

# E: ファイルシステム破損
EXT4-fs error (device sda1): ext4_find_entry: reading directory lblock

sector 付きの medium error が出ていれば A（ディスク不良）がほぼ確定。link down / reset が並ぶなら B（接続）。disconnect なら C。これで以降の手順が決まる。

EIO を返したファイルやデバイスを 再度叩く前に ログを取る。瀕死のディスクは読み直すたびに状態が悪化することがある。「とりあえずもう一度 cat」は最悪手。

ディスク障害を疑うには？（SMART）

結論: dmesg に medium error / sector が出たら smartctl でディスクの自己診断値を見る。Reallocated_Sector_Ct や Current_Pending_Sector が増えていれば物理劣化。バックアップと交換を急ぐ。

smartmontools の smartctl で SMART 情報を読む（未導入なら apt install smartmontools / dnf install smartmontools）。

# 健康サマリ
sudo smartctl -H /dev/sda

# 全属性
sudo smartctl -a /dev/sda

注目する属性。

ID# ATTRIBUTE_NAME          RAW_VALUE
  5 Reallocated_Sector_Ct   48      ← 代替処理済み不良セクタ。増加=劣化
197 Current_Pending_Sector  16      ← 代替待ちの不審セクタ。EIO の直接原因
198 Offline_Uncorrectable   16      ← 回復不能セクタ
199 UDMA_CRC_Error_Count    120     ← ケーブル/接続由来（ディスク本体は無事のことも）

Current_Pending_Sector / Reallocated_Sector_Ct が 0 以外で増えている → ディスク本体の劣化。寿命と判断しデータ退避＋交換へ。
UDMA_CRC_Error_Count だけ高い → ケーブル/接続（B）の可能性。挿し直し・交換で直ることがある。

short テストで裏取りもできる。

sudo smartctl -t short /dev/sda     # 数分後に -a で結果確認

SMART が劣化を示したディスクは いつ完全に死んでもおかしくない。fsck や badblocks -w（書込テスト）を先にかけると、残った読めるデータごと失う。順序は必ず ①退避（ddrescue）→ ②検査・修復。健全なディスクへコピーを取るのが最優先。

ファイルシステム破損か切り分けるには？

結論: dmesg が EXT4-fs error 等の FS 破損を示し、SMART は健全なら、fsck でメタデータを修復する。ただし fsck は 必ずアンマウント状態 で。マウント中の実行は破損を悪化させる。

まず読取専用で問題を確認（-n は一切書き込まない）。

# 対象を特定（マウント状態の確認）
lsblk -f
findmnt /mnt/data

# アンマウントしてから検査（-n = 読取専用ドライラン）
sudo umount /dev/sda1
sudo fsck -n /dev/sda1

ルートファイルシステム（/）が対象でアンマウントできない場合は、fsck をブート時に実行させるか、ライブ USB / レスキューモードから行う。

# 次回ブート時に強制 fsck（root FS 向け）
sudo touch /forcefsck      # systemd 環境では fsck.mode=force カーネル引数が確実

問題が確認できたら実際に修復する。重要データは退避済みであることが前提。

sudo fsck -y /dev/sda1     # -y = 修復を自動承認

fsck をマウント中の FS に実行してはいけない。カーネルとツールが同じメタデータを別々に書き換え、軽微な破損が致命傷になる。umount できない（device is busy）場合は「device is busy」でアンマウントできない時の対処を参照。

ディスク以外の原因のときは？

結論: dmesg に link down / disconnect / nfs ... not responding が出ているなら、ディスク本体ではなく 接続・切断・ネットワーク が原因。物理確認や再マウントで直ることが多く、fsck は不要。

接続・ケーブル（B）

UDMA_CRC_Error 高、SATA link down / ata reset が並ぶケース。

SATA/USB ケーブルを挿し直す・別ポート/別ケーブルに替える
外付けは 電源不足 が定番。セルフパワーの USB ハブや AC アダプタを使う
改善するか dmesg を監視（dmesg -w でリアルタイム）

デバイス切断（C）

USB disconnect の場合、/dev/sdX が消えて以降の全操作が EIO になる。

lsblk                       # デバイスが見えるか
sudo dmesg -w               # 挿し直した瞬間を観測

抜けたデバイス上のマウントは無効。アンマウントして挿し直し、再マウントする。

ネットワークストレージ（D）

NFS サーバ断やネットワーク障害でも EIO になる。サーバ側・経路を確認する。

mount | grep nfs
ping <nfs-server>
showmount -e <nfs-server>    # エクスポートが見えるか

ハングした NFS は「Stale file handle」の対処も併読。Stale file handle (ESTALE) は EIO と紛らわしいが対処が異なる。

緊急時のデータ退避はどうする？

結論: 死にかけのディスクからは、通常の cp ではなく ddrescue で退避する。読めるブロックを先に確保し、不良ブロックは後回し・スキップするので、最大限のデータを救える。

cp は EIO に当たると止まり、再試行でディスクをさらに痛める。gddrescue（apt install gddrescue / コマンド名は ddrescue）は不良を飛ばしながら救出し、ログで再開もできる。

# /dev/sdb（障害ディスク）→ /dev/sdc（健全な退避先）
# 第3引数のマップファイルで中断・再開が可能
sudo ddrescue -d -r3 /dev/sdb /dev/sdc rescue.map

-d … ダイレクト I/O（OS キャッシュを介さず実セクタを読む）
-r3 … 不良ブロックを最大 3 回まで再試行
rescue.map … 進捗マップ。中断後 同じコマンドで続きから 再開

ファイル単位ではなくデバイス/パーティション丸ごとを退避先に取り、退避先に対して fsck やファイル復旧をかけるのが定石。元の瀕死ディスクへの操作回数を最小化するのが目的。

最短フロー: ① dmesg -T \| grep -i error で原因系統（A〜E）を判定 → ② medium error なら smartctl -a でディスク劣化を確認 → ③ 劣化なら即 ddrescue で退避 → ④ FS 破損は退避後に fsck（要 umount）→ ⑤ link/disconnect/NFS は物理・経路を確認。dmesg を飛ばさないのが全ての起点。