【完全網羅】Linuxフォルダ構成・ディレクトリ構造の役割と違いを解説！実務で迷わないFHS 3.0準拠リファレンス

普段、インフラ構築やソフトウェア開発の現場で何気なく触っているLinuxのフォルダ構成。 「/bin と /sbin の使い分けって何だっけ？」 「独自に導入するパッケージ外のツールは、/usr/local と /opt のどちらに置くのが美しい設計だろう？」 と、実務でふと判断に迷った経験はありませんか？

Linuxのディレクトリツリーには、半世紀近くにわたり洗練されてきた「Filesystem Hierarchy Standard (FHS)」という統一的な標準設計仕様が存在します。

本記事は、歴史的な仕様の成り立ちから、FHS 3.0に基づくディレクトリの全役割、実務で迷いやすい類似フォルダの決定的な違い、/lost+found による救済の仕組み、さらには現代の「UsrMerge」 や最新の「sbin/bin統合」トレンド までを網羅した、「これさえあれば、もう迷わない」エンジニアのための完全バイブルです。

📌 実務でいつでも辞書として引けるよう、ぜひブラウザのブックマーク（お気に入り）に登録してご活用ください！

Linuxのフォルダ構成・ディレクトリ構造

Linuxのディレクトリ設計を支える「2つの重要思想」

具体的なディレクトリの解説に入る前に、知っておくとすべての辻褄が合う「Linuxファイルシステムの根本設計思想」を2つ整理しておきましょう。

① 「すべてはファイルである」という一元管理思想

Unix系OSから脈々と受け継がれてきた設計原則の一つが「すべてはファイルである」という考え方です。

Linuxでは、通常のテキストデータやソースコードはもちろん、接続された物理ハードウェア、実行中のプロセス、ネットワークソケットに至るまで、システム上のあらゆるリソースがファイルシステム上のパスとして抽象化されます。

そして、どれほど複雑な物理ディスクパーティションやネットワークマウントが存在しようとも、システム全体の起点であるルートディレクトリ（/）を頂点とする単一の階層構造ツリーの配下にすべてが一元的に配置されます。

② FHS（Filesystem Hierarchy Standard）によるデータ分類軸

このツリー上の配置ルールを標準化しているのが FHS です。

2015年に策定された「FHS 3.0」は、長らくLinux Foundationによって維持されていましたが、2025年11月6日以降はFreeDesktop.orgがその保守とメンテナンスを引き継いでいます.

FHSでは、システム内のすべてのデータを「共有可能か否か（Shareable vs. Unshareable）」および「静的か可変か（Static vs. Variable）」という2つの性質のマトリクスを用いて厳密に分類し、配置場所を定義しています.

• 共有可能（Shareable）データ：ネットワークを経由して複数の異なるホスト間で共通して利用・マウントできるデータ。ユーザーのホームディレクトリ（/home）や、OSの標準プログラムライブラリ群（/usr）などが該当します。
• 共有不可能（Unshareable）データ：特定のマシン（ホスト）に固有であり、他ホストと共有することが不適切なデータ。システム個別の設定ファイル（/etc）や、実行中のプロセスIDを記録する揮発メタデータ（/run）などが含まれます。
• 静的（Static）データ：システム管理者が明示的にアップデート（介入）しない限り変更されない、不変なデータ。プログラムの実行バイナリ、ライブラリ、オンラインマニュアルなどです。
• 可変（Variable）データ：システムの通常運用プロセスの中で、デーモンやユーザーアプリケーションによって頻繁に書き換えや追記が行われるデータ。ログファイル（/var/log）や一時ファイル（/tmp）が代表例です。

FHSにおけるデータ分類マトリクス表

この分類境界を徹底して分離する最大の合理性は、ストレージ管理の効率化と耐障害性の向上にあります。

たとえば、静的かつ共有可能なデータが集約された /usr ディレクトリは、安全に「読み取り専用（Read-Only）」としてマウント可能です。これにより、OSの基盤ファイルが意図せず（あるいは攻撃者のプロセスによって）改ざんされるリスクを根本から排除できます。

基本ディレクトリの定義、FHSによる分類区分、システム再起動時のデータの永続性、そして実務における管理者目線でのベストプラクティスを、1枚の比較シート表に集約しました。

インフラ構築やスクリプトでのコマンドの配置先、容量調査時に迷ったら、このマトリクス表にいつでも立ち返ってみてください。

ディレクトリパス	FHSデータ分類区分	再起動時のデータ永続性	実務での役割と管理者向けベストプラクティス
/bin	共有可能 / 静的	永続	すべてのユーザーが起動・緊急時にも使える必須の基本ユーティリティ。現代は /usr/bin へのシンボリックリンク。
/sbin	共有不可能 / 静的	永続	rootユーザー（管理者）専用のシステムブート・修復用コマンド。現代は /usr/sbin へのシンボリックリンク。
/boot	共有不可能 / 静的	永続	カーネルや初期RAMディスクなどブートローダーの静的データ。削除厳禁、容量不足に注意。
/dev	共有不可能 / 可変	揮発 (動的再構築)	接続デバイスを抽象化した仮想ファイルシステム。手動操作は行わず、カーネルと udev の管理に任せる。
/etc	共有不可能 / 静的	永続	ホスト固有の静的な各種設定ファイルの集約地。バイナリの配置は禁止。Git等でのバージョン管理推奨。
/lib	共有不可能 / 静的	永続	/bin や /sbin に連動するOS基盤用の必須共有ライブラリ群。現代は /usr/lib へマージ。
/media	共有可能 / 可変	接続時のみ	USBやCD-ROMなどの自動マウント（OSシステム自律制御用）。
/mnt	共有不可能 / 可変	一時的	管理者が手動（mount コマンド）で一時的に使用する空のマウントポイント。自動ツールと競合しない。
/opt	共有可能 / 静的	永続	パッケージ管理外のサードパーティ製品を独自のモノリシック階層で配置する領域。
/run	共有不可能 / 可変	揮発 (tmpfs)	起動中プロセスの実行時状態（PID、ソケットなど）。再起動で中身は完全に消滅する。
/srv	共有可能 / 可変	永続	Web公開用データなどのホストが提供するネットワークサービス用の公開コンテンツ。
/tmp	共有不可能 / 可変	揮発 (原則ブート時消去)	全プロセス・ユーザー用の一時ワーク領域。スティッキービットによる削除権限の制限あり。
/usr	共有可能 / 静的	永続	一般コマンド、共有ライブラリ、ドキュメントを格納するOSコアの実質最大領域。読み取り専用マウント可。
/usr/local	共有可能 / 静的	永続	パッケージ管理外で独自ビルドしたツールを格納する、全ユーザー共通の安全な置き場所。
/var	共有不可能 / 可変	永続	ログ、データベース実データ、パッケージキャッシュなど動的増幅を伴う可変データ。容量圧迫に最も注意。
/var/tmp	共有不可能 / 可変	永続 (再起動を跨ぐ)	大容量バッチ処理や再開予定のあるジョブのための一時保存領域。物理ディスクに実在。
/root	共有不可能 / 静的	永続	特権管理者（root）専用のホーム領域。ブート時やシステム緊急復旧に備えて /home から物理隔離。
/home	共有可能 / 可変	永続	一般ユーザーごとの個人スペース。OS再インストールや換装に備え、別ディスク・別パーティション構成が推奨。

ルート直下ディレクトリの網羅的リファレンス

ルートディレクトリ（/）の直下、およびOSの挙動を支える主要なディレクトリの定義、FHSによる要件、配置される主要オブジェクトについて詳しく見ていきましょう。

/bin：一般ユーザー向けの基本コマンド

• 主な役割と要件：システム起動時、緊急復旧時（シングルユーザーモード）、あるいは他のファイルシステムが一切マウントされていない極限状態でも、すべてのユーザーが即座に使用可能な「必須の実行ファイル」を配置します。
• 配置される主要ファイル：ls, cp, mv, cat, bash, chmod, echo, kill。
• モダン仕様：現代の多くのディストリビューションでは、後述の「UsrMerge」により、/bin は /usr/bin へのシンボリックリンクとなっています。

/sbin：システム管理者用の基本コマンド

• 主な役割と要件：システム起動、シングルユーザーモードでのファイルシステム修復、あるいは障害復旧時に、主にシステム管理者（root）が使用する「必須のシステム管理用バイナリ」を格納します。
• 配置される主要ファイル：fdisk, fsck, ifconfig, reboot, shutdown, mount.
• モダン仕様：/bin と同様、UsrMergeにより /usr/sbin へのシンボリックリンクとして構成されることが一般的です。

/boot：起動プロセスに必要な静的ファイル

• 主な役割と要件：コンピュータの電源を入れ、Linuxカーネルがメモリ上にロードされてユーザー空間プロセスを起動するまでに不可欠な「静的ブートローダー関連データ」を格納します。
• 配置される主要ファイル：vmlinuz（圧縮されたカーネル本体）、initrd.img（起動時に仮マウントされる初期RAMディスク）、grub/（ブートローダー設定）。
• 運用上の注意：この領域が削除されるとシステムは起動不能（ブート不可）に陥ります。通常、他の領域と切り離された100MB〜1GB程度の独立したパーティションとして構築されます。

/dev：ハードウェアやリソースを抽象化したデバイスファイル

• 主な役割と要件：Linuxの「すべてはファイルである」を象徴する領域です。接続された物理ハードウェアやシステム内部の仮想デバイスが、通常のファイルのように読み書きできるようマッピングされます。
• 配置される主要ファイル：
  • /dev/sda：1番目の接続ディスク（SSD/HDD）
  • /dev/tty：端末デバイス（仮想コンソール）
  • /dev/null：書き込まれたデータをすべて捨てる仮想デバイス
  • /dev/zero：無限にゼロ（null文字）のデータストリームを吐き出すデバイス
• 実態：物理的なファイルがディスクに書き込まれているわけではなく、カーネルと udev などのユーザー空間デーモンが連携し、メモリ上で動的に構築する仮想ファイルシステムです。

/etc：マシン固有のシステム設定ファイル

• 主な役割と要件：その物理マシンに固有の「静的システム設定ファイル」がすべて集約される、バックアップ対象としての最重要ディレクトリの一つです。
• 配置される主要ファイル：/etc/fstab（マウント管理テーブル）、/etc/passwd（ローカルアカウント情報）、各種ミドルウェアの設定（/etc/nginx/ や /etc/ssh/）。
• 制約事項：FHS規格により、/etc 配下に実行可能なバイナリ（プログラム本体）を直接配置することは厳格に禁止されています。

/lib：基本コマンドに必要な共有ライブラリ

• 主な役割と要件：ルートファイルシステム上の /bin や /sbin のバイナリを実行する、あるいは初期ブート時に必要なカーネルモジュール（ドライバなど）を読み込むために不可欠な「共有ライブラリ」を格納します。
• 配置される主要ファイル：libc.so.*（C標準ライブラリ本体）、ld-linux.so.*（動的リンカ）、modules/（カーネルモジュール群）。
• モダン仕様：マルチアーキテクチャ（32bit/64bitの共存）対応として、/lib64 や /lib32 などの修飾ディレクトリが追加される場合があります。UsrMergeシステムでは実体は /usr/lib にマージされます。

/media：取り外し可能な媒体の自動マウント用

• 主な役割と要件：USBメモリ、SDカード、CD-ROM、外付けHDDなど、リムーバブル（取り外し可能）な外部記録メディアの一時的な接続ポイントです。
• 動作形態：現代のシステムでは、メディアの挿入を検知したデスクトップマネージャーやマウントデーモンが、/media/cdrom や /media/usb といったサブディレクトリを動的に生成して自動接続（オートマウント）します。

/mnt：一時的な手動マウント用

• 主な役割と要件：システム管理者が、手動メンテナンスなどの目的で一時的に追加ディスクパーティションやネットワークストレージ（NFSなど）を接続するための、空のマウントプレースホルダーです。
• 実用方針：後述のように、自動マウントシステムと競合して意図しない上書きやエラーが生じるのを避けるため、手動介入専用の領域として完全に独立しています。

/opt：サードパーティ製アプリケーション

• 主な役割と要件：OSの標準パッケージ（apt, dnf等）から配布されるコアOS構成物とは無関係に、独立したプロバイダーから提供される「追加の大型アプリケーションパッケージ」のインストール先です。
• 構造上の特徴：/opt/google/chrome/ や /opt/adobe/ のように、インストールされる個々のソフトウェアが完全に自己完結した専用サブディレクトリ構造（bin、lib、share等）を持ちます。

/run：揮発性のシステム実行時データ

• 主な役割と要件：システムが起動してから現在までの、稼働中プロセスやデーモンの動作状態を管理する「実行時揮発データ」を格納します。FHS 3.0で必須ディレクトリとして定義されました。
• 配置される主要ファイル：プロセスの稼働を示すPIDファイル（nginx.pidなど）、UNIXドメインソケット、プロセス間ロックファイル。
• 実態：物理メモリをベースとする tmpfs（メモリベースの仮想ファイルシステム）がマウントされるため、システムのシャットダウンや再起動によって内部データは完全に揮発（消滅）します。

/srv：このホストが提供する各種公開データ

• 主な役割と要件：このサーバーシステムが外部クライアントへ向けて提供する「特定のネットワークサービス固有の公開データ」を論理的に一元管理・格納する領域です。
• 配置される主要ファイル：/srv/www/（Webサーバー用のHTML・画像・CGIなどの公開ツリー）や、/srv/ftp/（FTPサーバー公開ファイル）。
• 注意点：外部に公開されないアプリケーションデータなどは、ここではなく /var/lib に置くべきであるとFHSに記述されています。

/tmp：システムおよび全プロセスが利用する一時ファイル

• 主な役割と要件：システムや一般ユーザープロセスが、稼働中に「極めて短期的なライフサイクル」で作成する一時ワークファイルを置くためのグローバル書き込み許可領域です。
• 制約とセキュリティ：誰でも書き込める特性上、セキュリティ上の理由からパーミッションに「スティッキービット（Sticky Bit）」が設定されており、ファイルの所有者（またはroot）以外は、/tmp 内の他人の一時ファイルを削除できないよう保護されています。通常、リブート時にすべて削除されます。

/usr：ユーザー共有プログラムやアセット（OS実体の最大領域）

• 主な役割と要件：システムにおける「セカンダリのディレクトリ階層」であり、ユーザー間で共有するコマンド（ユーティリティ）、システムライブラリ、各種ドキュメントなど、OS実体の大部分がぎっしり詰まった最も広範な領域です。
• 下位の構成要件：
  • /usr/bin/：OS起動時に必須ではない、一般ユーザーやシステムのための主要アプリケーションコマンド（git, python, curl など）
  • /usr/sbin/：OS起動時に必須ではない、通常のシステム運用管理者向けコマンド（nginx, useradd など）
  • /usr/lib/：/usr/bin や /usr/sbin に配置されたプログラムが呼び出すライブラリ、および静的な設定アセット
  • /usr/share/man/：システムの各種オンラインコマンドマニュアル
  • /usr/local/：パッケージ管理外で、システム管理者が自律的に導入するローカルなツール群の配置領域

/var：動的に増大し続けるシステム可変データ

• 主な役割と要件：システムの稼働中に、デーモンやユーザープロセスによって絶えずサイズや内容が「変動し続ける永続的な可変データ」を格納する場所です。
• 下位の構成要件：
  • /var/log/：OSおよび各サービスが吐き出すシステム監査ログ、アプリケーションログ
  • /var/lib/：プログラムが稼働中に改ざん・更新する、システムの再起動をまたいで永続化される状態情報（例：PostgreSQL/MySQLなどのデータベース実データ、パッケージマネージャーのインストール履歴メタデータ）
  • /var/cache/：システムが重いI/Oや複雑な再計算をスキップするために一時的に格納する、最悪削除されてもアプリケーション自身の仕組みで再生成可能なキャッシュデータ（例：パッケージマネージャーがダウンロードした一時ファイル）
• 運用上の重要性：実務のインフラ監視において、最もディスク消費量が爆発しやすく、容量枯渇を引き起こしやすい要注意領域です。

/root：特権管理者専用のホーム

• 主な役割と要件：特権ユーザー（root）専用の独立したホームディレクトリです。一般ユーザーの /home とはあえて完全に物理的に切り離されています。
• 理由：/home ディレクトリが別ボリュームやネットワークディスク（NFS）で構成されている環境において、ネットワークトラブルなどでそれらがマウントできない状態になっても、rootユーザーだけは最小限のルートパーティション（/）にある /root からログインして緊急復旧作業を行えるようにする、というフェイルセーフ設計に由来しています。

/home：一般ユーザー個人の個別スペース

• 主な役割と要件：システムに登録された一般ユーザー各員に対して、個別のプライベート領域（/home/alice/ など）を提供するためのオプションディレクトリです。
• 運用方針：ユーザーごとの環境定義ファイル（.bashrc 等）や各個人の制作データ、開発中のソースコードなどが自由に置かれます。

FHSが規定する「/bin に絶対必要な必須コマンド群」

FHS規格は単に「ディレクトリの名前」を定義するだけではなく、システムに何かが起きて、他のすべてのマウントディスク（/usr など）が切り離された状態でも、システム管理者が /bin だけでシステムの修復・コピー・状態確認といった復旧作業を完全に完遂できるように、「最低限 /bin 内に存在しなければならないコマンド一覧」を厳格に規定しています。

FHS 3.0で /bin に設置が義務付けられている、主な必須標準ユーティリティは以下の通りです。

• cat：ファイルを連結して標準出力に出力する、最初期のログ検証や設定確認の命綱。
• chmod / chown / chgrp：ファイルやディレクトリの所有者やセキュリティパーミッションを修復するための基本権限操作。
• cp / mv / rm / rmdir：破損したファイルを安全な領域に退避させたり、ディスク容量確保のために不要ファイルを削除するためのファイル基本操作。
• df：ファイルシステムのディスク容量不足状況をスキャンして割り出す、修復のための最重要測定ツール。
• dmesg：起動プロセスにおけるカーネルのリングバッファメッセージを出力し、デバイスやハードウェアのエラーを即時特定する。
• kill：暴走している、あるいは緊急終了が必要なプロセスにシグナルを送信して制御する。
• hostname / date：システムが今どこで、何時何分に動作しているかを表示・設定する。

このように、/bin の中身は「ただのコマンドリスト」ではなく、OSが崩壊しかけた状況でも確実にサバイバルするための、選び抜かれた「非常用救急箱」のような構成になっているのです。

実務で絶対迷う！「類似ディレクトリ」の決定的な使い分け

システム構築やデプロイ、スクリプト作成を行っている際、エンジニアが最も遭遇しやすい「そっくりな役割のディレクトリの違い」を技術的な根拠とともに整理しましょう。

/bin と /sbin の違い：実行権限と「対象ユーザー」の使い分け

どちらも起動に必要な基本プログラム群を格納していますが、対象ユーザーとプロセスの目的が明確に分かれています。

• /bin（User Binaries）： システムにログインする一般ユーザー、管理者、そして各種システムサービススクリプトの「全ユーザーが広く日常的に使用する」基本コマンドを格納します（例：ls, cat, mkdir）。
• /sbin（System Binaries）： 主に「システム管理者（root）が実行することを前提とした」コマンドを格納します。ここにあるコマンド（例：fsck, fdisk, ifconfig）は、ハードウェアの直接的な設定変更やファイルシステムの破壊を伴う可能性があるため、通常、一般ユーザーのデフォルトの環境変数 $PATH からは除外されています。

/usr/local と /opt の使い分け：自作スクリプトとサードパーティ製品の配置ルール

どちらも「ディストリビューション公式のパッケージマネージャー（aptやdnf）の管理外のソフトウェア」を置く場所ですが、パッケージング（構造）の思想に決定的な違いがあります。

• /usr/local： ソースコードから手動ビルド（./configure && make && sudo make install など）した「UNIX標準の設計構造を維持したソフトウェア」を配置します。 この配下は /usr と同じように、bin/、lib/、share/ といった階層があり、異なるソフトウェアを手動インストールしても、実行ファイルは /usr/local/bin に、ライブラリは /usr/local/lib に集約されます。
• /opt： ベンダーが配布する「自己完結型、あるいはモノリシック（一体型）なサードパーティ製品」を配置します。 システムライブラリ（/usr/lib）などに依存せず、自身の中に専用のライブラリやデータを一括内包した Windows風の「アプリ専用フォルダ」を /opt/app_name/ として配置します。アンインストールは対象フォルダをそのまま削除するだけで完全に完了するため、システム標準ライブラリ群への干渉を防ぐことができます。

/media と /mnt の違い：自動認識と手動マウントの境界線

どちらも「外部のファイルシステムをマウントする場所」ですが、制御の主体が完全に分かれています。

• /media： OSやストレージ管理デーモンといった「自動システムが自律的に管理・マウントする場所」です。USBメモリやDVDなどを差し込んだ際、OSが動的にフォルダを作成して自動マウント処理を行います。
• /mnt： システム管理者が「手動マウントコマンド（mount）を使って、一時的なメンテンナンス作業を行うために占有する場所」です。自動化デーモンによる予期せぬ自動スキャンや自動変更の割り込みを防ぎ、安全な手作業を保証するために設計されています。

/tmp と /var/tmp の違い：一時ファイルの生存期間（ライフサイクル）の使い分け

どちらも「一時ファイル」を格納する場所ですが、再起動を跨いだデータの「生存保証（ライフサイクル）」が全く異なります。

• /tmp： 生存期間が「きわめて短い、完全に使い捨ての一時データ」の置き場所です。 多くのLinuxでは、物理ストレージではなくメモリ（tmpfs）上に割り当てられているか、あるいはシステムの再起動（ブート）の過程において、初期化スクリプトなどによって中身が完全に自動消去される仕組みになっています。
• /var/tmp： 「システムの再起動（リブート）を跨いで保持し、継続利用する必要がある一時データ」の置き場所です。 メモリではなく物理ストレージ（SSD/HDD）上に実在するため、不測のシャットダウンやシステムの再起動後もデータは失われません。長時間稼働する大容量バッチ処理の中間データや、レジューム機能を持ったプログラムの処理バッファ等に適しています。

ファイルシステム救済の舞台裏：/lost+found の動作原理と復旧設計

システムに電源トラブル、突発的なフリーズ、カーネルパニックが生じて強制停止した際、ディスクのルート直下に自動生成される /lost+found というディレクトリがあります。

普段はただの空っぽなディレクトリですが、ここにはファイルシステムのデータ保全と自己修復における、非常に深い「救済の動作原理」が隠されています。

inodeの孤立：ファイルが「迷子」になるメカニズム

Linuxにおけるファイル保存処理は、以下の3つのメタデータがアトミックに連動することで成立しています。

1. データブロック：ディスク上の、ファイルの中身が書き込まれるデータ実体領域。
2. inode（アイノード）：ファイルの所有者、サイズ、アクセス権限、およびデータ実体がディスクのどこにあるかを指し示す管理属性（i-node）。
3. ディレクトリエントリ：ファイル名と、上記「inode番号」をマッピングして、人間に見えるファイルパスにする紐付けデータ。

書き込み処理が進行している真っ最中にシステムが急停止すると、「データブロックが割り当てられ、inodeも正常生成されたのに、ファイル名とinodeをマッピングする『ディレクトリエントリ』が物理ディスクに書き込まれる前に電源が落ちてしまった」という、不整合な中間状態が発生します。

これが、リンク関係を失った「孤立したinode（Orphaned Inode）」です。ディスク上の容量を確かに消費し、中身も実在しているにもかかわらず、名前（パス）が存在しないため、通常の手段では二度とアクセス不可能な状態になってしまうのです。

fsck による救助とファイル生成の仕組み

次回のシステム起動時、OSは強制終了フラグを検知してファイルシステムチェックユーティリティ（fsck）を自動的に実行します。fsck はメタデータを走査し、どこからも名前を参照されていないにもかかわらず、使用中とマークされたままになっている孤立inodeを発見します。

fsck はデータをレスキューしようとしますが、元々の「ファイル名」や「所属していたディレクトリ」は完全に消失しているため、ファイルを修復した上で、ファイルシステムごとの避難所である /lost+found に自動的に再格納（退避）させます。

このとき、ファイル名は元の名前がわからないため、シャープ記号と対象のinode番号を組み合わせた形式（例：#2105）で仮命名され、再マウント後に管理者が中身を検証できるように復元されるのです。

なぜ /lost+found の再作成には mklost+found コマンドが必要なのか？

もし、このフォルダを誤って削除してしまった場合、単に mkdir lost+found とするだけでは不十分であり、専用の mklost+found ツールを使って作成し直す必要があります。

fsck が動く障害修復フェーズは、ファイルシステムが深刻に損傷しているか、もしくは読み取り専用マウントなどのきわめて不安定な極限状況です。

そのような一触即発の状態で、fsck が孤立した数千個ものファイルエントリーを一挙に /lost+found 内に書き込む際、ディレクトリファイル自体のサイズを拡張するために「新規のディスク空きブロックを走査・確保する書き込み（アロケーション）」を実行しようとすると、その追加負荷によってファイルシステム自体の破壊をさらに拡大させる深刻な二次災害（メタデータの汚染）が発生する恐れがあります。

そのため、mklost+found ツールはディレクトリを作成した時点において、あらかじめ非常に大きなディレクトリエントリ用のデータ領域を事前にディスク上に直接確保（Pre-allocation）し、空のブロックとしてマッピングを完了させておきます。

これにより、修復時の fsck は余分なアロケーション処理を一切行うことなく、アトミック（安全・確実）に迷子ファイルを /lost+found に再接続して保存できるのです。

実務ですぐに使える！ディスク容量調査の便利コマンド解説

サーバー管理の現場で「ディスク容量が100%になり、システムやミドルウェアが正常に動かなくなった！」という緊急事態が発生した際、どのディレクトリを最優先で確認すべきかを迅速に見極めるための実用的なコマンドです。

① システム全体の空きスペース状況を俯瞰する：df -h

まずは、システム全体のどのマウントポイント（パーティション）に、データが詰まっているかを確認します。

• df は「disk free（ディスクの空き容量）」の略です。
• -h を指定することで、バイト数ではなく「1.2G」や「450M」といった、人間が読みやすい1024進数の単位でマウント情報や使用量を整形して表示してくれます。
• ここで、ルート（/）や、可変データの集積地である /var が100%になっていないかを最優先で確認します。

② ルート直下のどこが最も大容量なのか犯人を特定する：du -sh /*

全体容量が詰まっているマウントポイントを特定したら、次は具体的に「どの第1階層フォルダが最も容量を肥大化させている犯人なのか」を割り出します。

• du は「disk usage（ディスク使用量）」の略です。
• -s でディレクトリ配下の合計サイズのみを計算し（要約表示）、-h で単位を見やすくします。
• 一般ユーザーではアクセスできないフォルダ（/root など）を正確に計算するため、必ず sudo（管理者権限）を付与して実行します。
• 2>/dev/null によって、パーミッション制限エラーなどのエラーノイズ出力を非表示にします。
• sort -rh にパイプで繋ぐことで、大容量（G、M）のフォルダを順番に最上部から並び替え（ソート）して瞬時に表示します。

③ 階層を限定して、容量の内訳を特定する：du -h -d 1 の深度制限

「/var が容量を食い潰していることは分かったけれど、内部の全サブディレクトリや細かいファイルまで再帰的にリスト表示されてしまうと画面が埋まって分析しにくい……」 そのようなときは、スキャンするツリーの深さ（深度）を「1階層まで」に制限して合計使用量を割り出す手法がスマートです。

• -d 1（または --max-depth=1）により、指定したディレクトリの1階層目にあるサブディレクトリそれぞれの合計容量だけを一覧出力させます。
• これにより、「/var/log（システムログ）が肥大化している」のか、あるいは「/var/lib（Dockerコンテナイメージやデータベースの実データ）が容量を逼迫させている」のかを、完全に特定・判断することができます。

【参考コラム】XDG Base Directory Specification

FHSが定義する「システムレベルのファイル役割分離思想」は、一般ユーザーが自由に扱えるべきホームディレクトリ（$HOME）の内部空間設計にも相似形としてそのまま投影されています。

かつて、Linuxのデスクトップアプリや開発ツールは、ユーザーごとの設定やデータを、$HOME 直下に .app_name/ などのドットファイル（隠しフォルダ）を勝手に生成して保存する慣習（ドットファイル地獄）がありました。

この状態は、ホーム直下の名前空間を激しく汚染するだけでなく、「どれがGitでバージョン管理すべき設定ファイルで、どれがいつでも安全に消去可能な一時キャッシュデータなのか」を、ユーザー（エンジニア）が客観的に判別できないという重大な運用課題を抱えていました。

これを解決するために策定されたのが、FreeDesktop.orgによる XDG Base Directory Specification です。XDG仕様では、以下の主要な環境変数を用いて、データの性質（設定・静的・可変・一時）をホームディレクトリ内で完全に切り分けます。

環境変数	デフォルトの物理パス	FHSにおける対応関係	格納されるデータの性質と管理方針
$XDG_CONFIG_HOME	~/.config[cite: 46]	/etc (システム設定)	アプリケーションのユーザー固有「設定ファイル」を格納。Git等でのドットファイル管理対象となる不変領域。
$XDG_DATA_HOME	~/.local/share[cite: 46]	/usr/share (共有リソースデータ)	アプリケーションの実行に必要な、設定以外の「重要なユーザーデータ（例：チャット履歴、セーブデータ）」を格納。
$XDG_CACHE_HOME	~/.cache[cite: 46]	/var/cache (キャッシュ)	アプリケーションが実行中に作成する「いつでも再生成可能な一時キャッシュ」を格納。容量逼迫時にいつでも丸ごと消して良い領域。
$XDG_STATE_HOME	~/.local/state[cite: 46]	/var/lib (永続的な状態)	アプリケーションが再起動を跨いで維持したい、履歴、ログ、現在状態などを格納。
$XDG_RUNTIME_DIR	/run/user/<UID>[cite: 46]	/run (揮発実行時状態)	ログインセッション中のみ有効な「極めて揮発性の高いソケットや通信用データ」を格納。ログアウト時やリブート時に自動消去される。

このXDG仕様は、FHSの精神をデスクトップレベルへ美しく適用したものです。

しかし、現実のソフトウェアにおいて完璧に普及するまでには、長い歳月がかかりました。たとえば、Webブラウザの Firefox は、独自の強力なプロファイル設計を維持していたため、XDG仕様へのネイティブ対応を果たすまでに実に17年もの開発ディスカッションと歴史を要しました。

また、Signal-Desktop など一部のElectronフレームワーク製のチャットツールやデスクトップアプリにおいては、本来であればバックアップや他ホストへの移植性が低い、受信した画像などのアタッチメント（添付ファイル）実データを、あろうことか設定フォルダである $XDG_CONFIG_HOME（~/.config）の直下に直接格納してしまい、結果的に設定だけのバックアップや管理を妨げるという設計バグ（標準仕様の誤解）が生じるなど、実装の現場では依然として細かな課題が存在しています。

まとめ：ディレクトリ構造を知ってトラブルに備えよう

Linuxのディレクトリの「なぜそこにあるのか」という歴史的背景や論理的基準を、一歩深く理解しておくと、普段の開発や障害対応におけるトラブルシューティングのスピードは劇的に向上します。

実務や設計で迷ったときは、本記事の比較シートやコマンド集をぜひ繰り返し活用してみてください！