容量が余っているのにファイルを作れない理由

一言でいうと

ストレージは、ブロックデバイス → パーティション → ファイルシステム → マウントの4つの階層で積み上がります。障害が起きたときに最初にすることは、症状がどの階層のものかを決めることで、その判断だけで、候補が4分の1に絞れます。

なぜ必要なのか

df -hは35GB残っていると言っているのに、touch1つがNo space left on deviceで失敗します。ここで「監視がおかしい」と結論づけやすいですが、dfは正直にブロックの使用量を報告しただけです。このエラーはerrno 28で、カーネルがこの値を返す経路は、ブロック不足のほかにも複数あります。

最もよくあるのが、inodeの枯渇です。ファイル1つは、データブロックとは別に、メタデータを持つinodeを1つ使います。ext4はinodeの個数がファイルシステムの作成時点で固定されるので、ごく小さなファイルが大量に溜まると、ブロックが余っていてもinodeが先に尽きます。確認はdf -iで、IUse%が100なら答えが出たことになります。増やせないので、ファイルを消すか、ファイルシステムを作り直すしかありません。セッションファイル、溜まったメールキュー、整理されない一時ファイルが、常連の原因です。

次の候補も、知っておく価値があります。削除されたが開かれているファイル。ディレクトリエントリは消えているのでduは見つけられませんが、プロセスが開いているので、ブロックが返却されません。dfとduがずれる最もよくある理由です。予約ブロック。ext系は、デフォルトで一定の割合をroot専用として残しています。マウントによる隠蔽。ファイルがあるディレクトリの上に別のファイルシステムをマウントすると、下のファイルは見えないのに、領域は占有し続けます。

そして、診断の前に30秒を使う価値のある確認が1つあります。本当にそのファイルシステムに書き込んでいるのか。df -hを引数なしで実行して、一覧を目で流し見して推測するのが、最もよくある間違いです。findmnt -T <경로>で、そのパスが実際にどのデバイスに属しているかを直接尋ねれば、/ではなく、別パーティションの/varがいっぱいになっている状況をすぐに見抜けます(プレースホルダーはパスです)。/tmpがtmpfsの環境もよくありますが、ここがいっぱいになると、ディスクとは無関係に同じエラーが出て、その分の物理メモリを食っています。

どう動くのか

/etc/fstabの6つのフィールド。

番号	フィールド	説明
1	デバイス	UUID、LABEL、またはデバイスパス
2	マウントポイント	取り付けるディレクトリ
3	ファイルシステムの種類	ext4、xfs、nfsなど
4	オプション	defaults、noatime、nofailなど
5	dump	バックアップツール用。通常は0
6	fsckの順序	ルートは1、残りは2、検査しないは0

UUIDを使う理由は、デバイス名が安定していないからです。/dev/sdbは、カーネルがデバイスを発見した順序で付く名前なので、ディスクを1つ追加したり、コントローラーが変わったりすると、別のディスクがその名前を持っていくことがあります。そうすると、fstabは文法的には問題ないまま、見当違いのデバイスをマウントします。UUIDはファイルシステムに刻まれているので、デバイスがどこに挿されていても、ついて回ります。

オプションのうち、nofailは特に実務的です。これがないと、そのデバイスがないときに、起動が緊急モードに落ちます。外付けディスクやネットワークストレージのエントリには、たいてい付けます。

LVMが解く問題。パーティションは、ディスクの上に固定された境界を引く方式なので、あとで拡張するには、後ろに隣接する空き領域が必要です。LVMは、物理ボリューム(PV)をボリュームグループ(VG)というプールにまとめ、そのプールから論理ボリューム(LV)を切り出して使います。そのため、複数のディスクにまたがる1つのボリュームを作れ、ディスクを追加してプールを大きくしたあとで、ボリュームをオンラインで拡張できます。スナップショットも、この階層から出てきます。

RAIDレベルは、要件が選びます。RAID 0は、性能と容量だけを与え、冗長化がまったくありません(ディスク1つが死ぬとすべてを失う)。RAID 1は、そのまま複製するので安全ですが、容量が半分です。RAID 5は、パリティ1つで1台の故障に耐え、容量効率がよいですが、リビルド中に残りのディスクをすべて読む必要があるため、そのときに2台目が故障したら終わりです。ディスクが大きくなるほど、リビルド時間が長くなり、このリスクが大きくなります。RAID 10は、ミラーをストライプして、書き込み性能とリビルドの安全性を得る代わりに、容量の半分を差し出します。そして、どのRAIDもバックアップではありません。RAIDはハードウェアの故障に耐える仕組みであり、誤って消したファイルを元に戻してはくれません。

現場での姿

筆者が経験した事例では、Availが35GBなのに、0バイトのファイル1つを作れませんでした。順番に確認すれば、5分で原因が出ます。パスが属するファイルシステムを確定し、df -iでinodeを見て、削除された開いているファイルを探し、予約ブロックとマウントによる隠蔽を確認します。この順序を覚えておく価値は大きいです。同じエラーメッセージが複数の原因から出るので、メッセージだけを見て推測すると、毎回違う道に逸れます。

dfとduがずれるときの最初の候補も、いつも同じです。削除されたがプロセスが掴んでいるファイルです。最も安全な解放方法は、サービスを再起動することではなく、ログファイルを開き直させるシグナルを送ることで、その次の手段が、ディスクリプターを直接空にすることです。順序を守る理由は、再起動がその瞬間の診断情報をすべて消してしまうからです。

次のクイズで確認すること

このラボ環境では、mount、umount、mkfs、fdisk、parted、pvcreate、swaponのようなコマンドが、すべて塞がれています。カーネルのcapabilityが取り除かれたコンテナなので、ファイルシステムを実際に作ったり取り付けたりできないからです。そのため、このモジュールは概念と判断基準に集中します。正直に言えば、ストレージはLFCSで、手で操作してみないと身につきません。だから、すぐ次のモジュール(本物のVMでLVM・mkfs・mount・swap・NFS・autofsを直接行うラボ)が、その練習の場です。ここでは、階層構造、dfとduの違い、inode枯渇の診断順序、fstabの各フィールドの意味とUUIDの理由、LVMとRAIDの選択基準を確実に押さえて、クイズで点検します。