ENOSPC（No space left on device）

一言でいうと（このエラーが何を意味するか）

ENOSPC は「No space left on device」に対応する POSIX のエラー番号（errno の 28）で、write(2)・open(2)（O_CREAT）・mkdir(2)・rename(2) などがデータを書き込めなかったときにカーネルが返します。アプリ側では write: No space left on device や Node.js の Error: ENOSPC として表面化します。

重要なのは、原因が 2 種類あることです。1 つはブロック（データ本体を置く領域）の枯渇。もう 1 つは inode（ファイルのメタデータ枠）の枯渇です。ext4 などは作成時に inode 数が固定されるため、1 バイトの空きが山ほどあっても inode を使い切ればもう 1 ファイルも作れず ENOSPC になります。df -h だけを見て「空いているのに直らない」と詰まる典型がこれです。

横にスクロール

よくある原因（複数を具体的に、頻度順）

• ログ・一時ファイルの肥大: ローテート未設定のアプリログ、journald、/tmp、APT/yum キャッシュがパーティションを埋める。最頻出。
• 削除したのに空きが戻らない: プロセスが開いているファイルを rm しても、ファイルの nlink（ハードリンク数）は 0 になるがプロセスが握るファイルディスクリプタが残る限り inode とブロックは解放されない。ログを rm したのにサーバーの空きが増えない、という症状の正体。
• inode 枯渇: メールキュー、セッションファイル、npm の node_modules、大量の小ファイルを作るバッチが inode を食い尽くす。df -h は余裕、df -i が 100%。
• Docker のディスク肥大: 未使用の image layer・停止コンテナ・匿名 volume・build cache が /var/lib/docker を埋める。ホストの ENOSPC の主犯になりやすい。
• 予約ブロックの壁: ext 系は既定で 5% を root 用に予約する。一般ユーザーのプロセスは 95% の時点で ENOSPC を食う（df は使用率 95% 前後を示す）。
• 特殊要因: inotify の watch 上限超過（ENOSPC を返すが実ディスクは無関係。エディタや webpack --watch で頻発）、スパースファイルの実書き込み、スナップショット領域の消費など。

診断の手順（切り分け方・見るべきログ／コマンド）

まずブロックと inode を両方確認します。ここを片方だけで済ませるのが最大の落とし穴です。

df -h        # ブロック容量。Use% と Mounted on を見る
df -i        # inode 使用率。IUse% が 100% なら inode 枯渇

どのマウントが満杯かを特定したら、その配下で消費元を絞ります。

# 大きいディレクトリ上位（対象FS内に限定して他マウントへ潜らない）
du -x -h --max-depth=1 /var | sort -rh | head -20

# inode枯渇時は「大きさ」でなく「ファイル数」で探す
find /var -xdev -printf '%h\n' | sort | uniq -c | sort -rn | head -20

「消したのに戻らない」を疑うときは、削除済み（nlink=0）を掴むプロセスを特定します。

# +L1 は「リンク数が1未満＝削除済みだが未クローズ」のファイルだけを表示
lsof +L1
# 出力の NLINK 列が 0、SIZE/OFF が巨大なものが原因。PID を再起動 or truncate

Docker が絡む場合は専用の内訳コマンドが早いです。

docker system df          # image/container/volume/build cache の内訳
docker system df -v       # 個別サイズの詳細

解決と予防（対処と再発防止）

対処は「原因の種類」で分岐します。

# 1) 肥大ファイルの縮小（追記中のプロセスを止めずに実体だけ0に）
: > /var/log/huge.log            # rm ではなく truncate。fd はそのまま生きる

# 2) 削除済み保持の解放：lsof +L1 で見つけた PID を再起動、または
truncate -s 0 "/proc/<PID>/fd/<N>"   # 該当fdの実体を縮める最終手段

# 3) journald の肥大を上限付きで整理
journalctl --vacuum-size=200M

# 4) Docker の不要データを一括回収（volume も消すなら --volumes は慎重に）
docker system prune            # 停止コンテナ・未使用network・dangling image・cache
docker image prune -a          # 未参照 image を全削除

inode 枯渇は「削除」でしか回復しません。ext4 は後から inode 数を増やせず、増やすには作り直し（mkfs -N／-i）が要ります。小ファイルが構造的に多いなら、inode を動的確保する XFS や Btrfs への移行が根本策です。予約ブロックはデータ用途のパーティションなら tune2fs -m 1 /dev/sdXN で 5%→1% に下げて実効容量を稼げます。

ファイルシステムの inode・ハードリンク・unlink の内部動作はOS、コンテナのレイヤ管理と /var/lib/docker 肥大の背景はDevOps、テーブルスペースや WAL でディスクを食う DB 側の枯渇はデータベースを参照してください。