この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
「なぜ？ 空きがあるのにファイルが作れない」——2003年、SEとして客先常駐していた頃の経験です。この謎を解くまでに数時間かかりました。答えはinodeの枯渇でした。
この記事では、セミナーで3,100名以上を指導してきた私が、inode枯渇の正体と、df -iコマンドを使った真因の特定手順、そして再発させないための3つの習慣を解説します。
この記事のポイント
・dfで空きがあっても「df -i」でinodeが100%ならファイルは作れない
・inodeはファイルの「管理情報スロット」でファイル1つにつき1つ消費する
・find /path -xdev -type f | wc -l でディレクトリごとのファイル数を数えられる
・小さなファイルを大量生成するアプリが主な原因
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「ディスクが空いているのにファイルが作れない」——謎の状況
2003年、私はSEとして客先のLinuxサーバーを担当していました。ある夕方、担当しているWebアプリのサーバーから「ファイルの書き込みに失敗している」という連絡が入りました。ログを確認すると、PHPアプリケーションがセッションファイルの作成に失敗していました。エラーメッセージはこうです。
Warning: session_start(): open(/tmp/sess_xxxx, O_RDWR) failed: No space left on device (28) in /var/www/html/index.php on line 3
# ディスク空き容量の確認 $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 40G 8.8G 31G 22% / /dev/sda2 10G 2.1G 7.9G 21% /var tmpfs 1.0G 0 1.0G 0% /dev/shm
数時間後に気づいたこと——inodeという概念
調査を続ける中で、私がたどり着いたのは「inode」という言葉でした。当時の私にはあまり馴染みがなかった概念です。先輩のエンジニアに相談し、別のコマンドを試すように教えてもらいました。# inodeの使用状況を確認する（dfに -i オプションを付ける） $ df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 2621440 2621440 0 100% / /dev/sda2 655360 98304 557056 15% /var tmpfs 256000 1 255999 1% /dev/shm
この状態では、ディスクに物理的な空き容量があっても、新しいファイルを1つも作れません。謎の答えが分かった瞬間でした。
inodeとは何か——Linuxのファイルシステムが管理する「ファイルの戸籍」
inodeはLinuxのファイルシステムが内部的に使う管理情報の単位です。ファイルやディレクトリ1つにつき、1つのinodeが割り当てられます。inode内には以下のような情報が格納されています。・ファイルの種類：通常ファイル・ディレクトリ・シンボリックリンクの区別
・パーミッション：所有者・グループ・その他の読み書き実行権限
・タイムスタンプ：作成日時・最終変更日時・最終アクセス日時
・データブロックの場所：実際のデータがディスクのどこにあるかを示すポインタ
重要なのは、inodeの総数はファイルシステムの作成時（mkfs）に決まり、後から増やせないという点です。ext4では通常、16KBごとに1つのinodeが作成される設定が多いですが、小さなファイルを大量に作るとinodeだけが先に尽きてしまいます。
原因のディレクトリを探す——findコマンドでファイル数を数える
inodeの枯渇が確認できたら、次は「どのディレクトリが大量のファイルを持っているか」を特定します。20年以上サーバーを運用してきた経験から言うと、inode枯渇の主な原因として最も多いのは、小さなファイルの大量生成です。1. ファイル数が多いディレクトリを特定する
まずルートからサブディレクトリごとにファイル数を数えます。-xdevオプションで他のパーティションをまたがずに調査できます。# 各サブディレクトリ配下のファイル数をカウントする（件数の多い順に表示） $ for dir in /*; do count=$(find "$dir" -xdev -type f 2>/dev/null | wc -l); echo "$count $dir"; done | sort -rn | head -10 2615233 /tmp 154820 /usr 8752 /lib 5614 /var 4801 /home 1832 /etc 124 /bin 42 /boot 0 /opt
2. /tmp配下のファイルを確認する
# /tmpのファイル一覧（lsは大量すぎて固まる可能性があるのでheadで先頭のみ確認） $ ls /tmp | head -10 sess_0a1b2c3d4e5f6a7b sess_1c2d3e4f5a6b7c8d sess_2e3f4a5b6c7d8e9f sess_3a4b5c6d7e8f9a0b sess_4b5c6d7e8f9a0b1c sess_5c6d7e8f9a0b1c2d sess_6d7e8f9a0b1c2d3e sess_7e8f9a0b1c2d3e4f sess_8f9a0b1c2d3e4f5a sess_9a0b1c2d3e4f5a6b
3. 不要なファイルを削除してinodeを解放する
大量のファイルをrmで一括削除する場合、引数が多すぎて「argument list too long」エラーになることがあります。findとxargsを組み合わせて安全に削除します。# まず削除対象のファイル数を確認する（実行前に必ずファイル数を把握する） $ find /tmp -maxdepth 1 -name 'sess_*' -type f | wc -l 2615233 # 実際に削除する（xargsで分割処理することで引数過多エラーを回避） $ find /tmp -maxdepth 1 -name 'sess_*' -type f | xargs rm -f # 削除後にinode使用状況を再確認する $ df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 2621440 6207 2615233 1% / /dev/sda2 655360 98304 557056 15% /var
inode枯渇を防ぐ3つの習慣
20年以上サーバーを運用してきた経験から、あの夜の経験が生んだ習慣を3つ紹介します。1. df -iを日次監視に追加する
dfだけではinode枯渇を検知できません。日次のヘルスチェックにはdf -hとdf -iの両方を含めることが鉄則です。監視ツールを使っている場合は、inode使用率のアラートを80%で設定しておくと余裕を持って対処できます。# ディスク容量とinode使用率を両方一度に確認するコマンド $ df -h && echo "---inode---" && df -i
2. 一時ファイルを作るアプリの設定を定期確認する
PHPのセッション管理、メールスプールのmbox、Apacheのアクセスログローテーションなど、小さなファイルを大量生成する可能性があるアプリは要注意です。以下の点を確認してください。・PHPの場合：session.gc_probabilityとsession.gc_maxlifetimeが有効になっているか
・一時ファイルの場所：/tmpや/varなどどのパーティションに作られるかを把握する
・ログローテーション：logrotateで古いログが定期的に削除されているか
セミナーで3,100名以上を指導してきた中で、inode枯渇で困っていたエンジニアのほぼ全員が「アプリ側の設定は確認していなかった」と話していました。
3. cronで古い一時ファイルを定期削除する
GCが機能している環境でも、念のためにcronで定期的に古い一時ファイルを削除するジョブを組んでおくと安心です。# 7日以上前のPHPセッションファイルを毎日午前4時に削除する（crontab記載例） MAILTO="" 0 4 * * * find /tmp -name 'sess_*' -mtime +7 -type f | xargs rm -f
まとめ
「No space left on device」なのにdfで空きがある——これはinodeの枯渇が原因です。2003年に経験したこの事故は、20年以上の運用で「知っているか知らないかで大違いな典型例」として今もセミナーで話し続けています。| やりたいこと | コマンド |
|---|---|
| inode使用率を確認する | df -i |
| ディレクトリごとのファイル数を数える | find /path -xdev -type f | wc -l |
| 大量ファイルを安全に削除する | find /tmp -name 'sess_*' | xargs rm -f |
| 現在のinode設定を確認する | tune2fs -l /dev/sda1 | grep -i inode |
本番サーバーのトラブル対応で「まず確認する手順」の全体像については「Linuxの本番サーバー作業でヒヤリハットした経験談｜現役講師が20年で学んだ事故を防ぐ3つの確認習慣」も参考にしてください。ディスクが急に満杯になった場合の対処については「Linuxでディスクが容量不足になった時の対処手順｜原因ファイルの特定から安全な削除まで」でも詳しく解説しています。
「No space left on device」で焦らない「本物のLinux力」を身につけませんか？
「エラーメッセージが出ると頭が真っ白になる」という方は多いです。現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxでrm -rfを打つ前に手が止まった日の話｜現役講師が語る削除コマンドへの恐怖と20年間変えていない確認の習慣
- 前のページへ：Linuxで初めてWebサーバーを公開した日の話｜現役講師が語るApacheが動いた瞬間の衝撃と3つの教訓
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます