ディスク診断マニュアル

容量、inode、機器の健全性、I/O 遅延は別問題として調べる。構成変更はストレージ手冊に集約する。デバイス名とパスは実機で確認して置き換える。

やりたいこと	参照先
容量不足	df と du の差
書込みが遅い	遅延と負荷
I/O error・読取専用	健全性と根拠

パスと実デバイスを対応付ける

# 対象ディレクトリを含む mount を特定する
findmnt -T /var/lib

-T はパス指定。SOURCE/FSTYPE/TARGET を読み、名前だけで独立 mount と判断しない。

# mount 元から block device の階層を確認する
lsblk -o NAME,TYPE,SIZE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS,MODEL

part/lvm/crypt/raid 等を確認する。SIZE は層の容量で、filesystem の空きではない。

# 安定 ID と現在の device 名を照合する
ls -l /dev/disk/by-id/

保守時は sdX だけでなく型番・serial・容量・slot も合わせる。

# filesystem の block 使用率と型を読む
df -hT /var/lib

Use% が 100% 近くなら容量を調べる。-h は可読単位、-T は型。

# inode 枯渇を別途調べる
df -i /var/lib

高い IUse% は小ファイル多数の可能性。inode の割当・統計は filesystem ごとに異なる。

TYPE と親子関係から LVM・暗号化・overlay・ネットワーク FS を確認する。/dev/sdb は変わり得るため by-id・型番・容量・マウント先を照合する。df はディスク全体でなく FS の値。

同じパスとマウント範囲で容量を比べる

同じ mount 範囲で使用量を探す

# filesystem をまたがず一階層の容量を調べる
sudo du -x -h --max-depth=1 /var/lib

大きい業務ディレクトリをさらに調べる。-x は同一 filesystem。権限エラーで過小集計になるので stderr を読む。走査も I/O を発生させる。

# 削除済みだが open されたままのファイルを探す
sudo lsof +L1

COMMAND/PID/SIZE/OFF/NAME と device を照合する。対応する log rotation・正常再起動で閉じ、未知の fd を切り詰めない。

# mount point の場合に配下の mount を調べる
findmnt -R /var/lib

通常のディレクトリなら -T で TARGET を取得して -R する。下層ファイルが隠れ、du/df の比較範囲が変わる。

# journal の容量だけを測る
journalctl --disk-usage

systemd 手順 の rotation・保持方針を使い、容量だけで active log を消さない。

GNU du の例。ディレクトリ自体を指定すれば隠し項目も含む。* 展開では漏れる。-x は FS を跨がない。lsof +L1 で削除済み open ファイルを調べ、所有サービスの正規手順でハンドルを閉じる。

観測	意味と次の確認
df: blocks 100%, inodes available	大きいディレクトリ、削除済 open、snapshot、予約領域を確認
df -i: IUse% 100%	小ファイルで inode 枯渇。配置先と保持方針を確認
df >> du	権限・範囲・隠し項目の後にハンドルと snapshot。集計方式の差もある
削除しても空かない	open、snapshot、ゴミ箱、同時増加を調べてから追加削除

対話表示は ncdu、検索は find/fd。fd は既定で ignore と隠し項目除外が働くため、必要な範囲なら -HI を指定する。Docker のデータ領域は大きいという理由で直接削除しない。

機器遅延とプロセス負荷を照合

# device の転送量・queue・遅延を継続観測する
iostat -y -xz 1

sysstat のツール。-y は起動後平均を除外、-x は詳細、-z は非稼働 device を省略、1 は秒。await/aqu-sz/転送量を障害時刻と照合する。

# I/O のある process に絞り累計を見る
sudo iotop -oPa

-o は活動のみ、-P は process、-a は累計。累計が大きくても現在速度が高いとは限らない。accounting・権限のエラーを読む。

# process の read/write と I/O delay を秒ごとに見る
pidstat -d 1

同時刻の iostat と比較する。page cache があるため毎秒の device 書込と一致するとは限らない。

# I/O による task 停滞の圧力を読む
cat /proc/pressure/io

some/full の avg10/60/300 は時間窓の割合、total は累計 microsecond。停滞の指標で、故障 drive の特定ではない。

iostat は sysstat。-y は起動以来の初回平均を省く。転送量・await・キュー・アプリ遅延を同期間で見る。%util だけで NVMe/RAID の限界とは決めない。iotop は権限と accounting が必要。

修復の前に根拠を保存

device 種別に応じて健康状態を読む

# 確認した SATA/SAS device の詳細を読む
sudo smartctl -x /dev/sdX

device を置換する。USB bridge は --scan-open と対応 -d を確認する。firmware 更新や長時間 self-test とは別。

# NVMe controller の健康ログを読む
sudo nvme smart-log /dev/nvme0

NVMe 用の選択肢。critical_warning/media_errors/temperature・消耗率の変化を見て、累計だけで新規故障と判断しない。

# reset・I/O error・read-only 化を時刻で照合する
journalctl -k -b --no-pager

前後の記録を保存する。hardware read error では原本を何度も強制修復せず、復旧可能な副本を優先する。

TRIM 対応と調度を確認する

# device 階層の discard 対応を読む
lsblk -D

DISC-MAX 等は能力の手がかりで、TRIM 実行済みの証明ではない。

# 定期 TRIM の設定を確認する
systemctl status fstrim.timer --no-pager

実行結果は fstrim.service の journal。既存計画を確認してから調度を検討し、重複・無条件 discard を避ける。

対象機器のコマンドを選ぶ。USB bridge は対応する smartctl -d が必要な場合がある。PASSED でも配線・電源・controller の問題は否定できない。カウンター増分・温度・媒体エラー・reset を見る。self-test の負荷と時間は機器による。

I/O error や読取専用化では不要な書込みを止め、バックアップと復旧経路を確認して原因を分ける。最初に remount,rw や fsck -y を使わない。オフライン検査はストレージ。TRIM は各層の対応と timer 方針を確認する。

GNU du · sysstat · smartmontools