别再死记 Linux 目录：从 FHS 到运行时文件系统

/usr：发行版提供的静态系统资源#

/usr 是主要的只读、可共享层。发行版或包管理器提供的大部分程序和静态资源都放在这里。

• /usr/bin：适合从命令行调用的程序。
• /usr/lib：库、包的私有数据，以及不打算让用户直接执行的内部程序。
• /usr/include：面向用户空间开发的头文件。
• /usr/share：与 CPU 架构无关的数据，例如手册、时区和 locale 数据。
• /usr/local：系统管理员在本机安装的软件层，避免与发行版管理的 /usr 文件发生冲突。

这里有一个容易踩的坑：/usr/include/linux 是提供给用户空间使用的 UAPI 头文件，不应该随手链接到任意内核源码树。编译外部内核模块时，常见入口是 /lib/modules/$(uname -r)/build；它通常再指向发行版为当前内核准备的构建目录。用户空间 ABI 和内核模块构建环境是两件事。

/etc：本机配置，而不是程序仓库#

/etc 保存 host-specific system configuration，也就是本机系统配置。主机名、服务配置、账号数据库和网络策略通常落在这里。

FHS 明确要求 /etc 不放二进制程序。现代系统还经常把发行版默认值放在 /usr，只把管理员覆盖的配置放在 /etc。于是配置的含义变得很清楚：/usr 是供应方给出的默认状态，/etc 是这台机器做出的决定。

/var：需要跨重启保留的变化#

/var 保存运行中会变化、而且通常要持久化的数据：

• /var/log：日志。
• /var/lib：应用持久状态，例如数据库、包管理器状态和 cloud-init 实例数据。
• /var/cache：可以重新生成的缓存。
• /var/spool：等待处理的队列，例如邮件和打印任务。
• /var/tmp：预期可以跨重启保留的临时文件。

“会变大” 不是判断 /var 的充分条件。配置文件也会变化，但它属于 /etc；用户文档也会变化，但它属于用户数据。关键问题是：这是不是系统或服务在运行中产生并需要保留的状态？

/run：只服务于本次启动#

/run 保存从本次启动开始才有意义的运行时数据，例如 PID 文件、Unix socket、锁和服务的瞬时状态。现代系统通常把它挂载为 tmpfs，所以重启后自然消失。早期放在 /var/run 和 /var/lock 的内容，如今通常通过兼容链接指向 /run。

/run 与 /var 的分界不是 “内存对磁盘”，而是生命周期：

• 重启后仍有意义，放 /var。
• 只描述当前这次启动，放 /run。

这条规则比死记 “PID 文件放哪里” 有用得多。

用户、临时文件与服务数据#

• /home：普通用户的主目录。程序应通过 $HOME 或用户数据库查找它，不要假定一定是 /home/<name>。
• /root：root 的主目录放在 /home 外，使 /home 尚未挂载时管理员仍可能登录修复。
• /tmp：短生命周期临时文件，可能在启动时或定期清理。多用户环境中必须用 mkstemp(3)、mkdtemp(3) 等安全接口创建文件。
• /srv：本机对外提供的服务数据，例如管理员维护的网站内容。
• /opt：附加软件包的独立目录。它仍在 FHS 中，但现代发行版是否使用它取决于打包策略。
• /boot：内核、initramfs 和引导加载器需要的静态文件。EFI 系统分区可能挂载在 /boot、/boot/efi 或 /efi，这是发行版和引导方案的选择，不是所有 Linux 都固定为 /boot/efi。

/dev：设备访问入口#

/dev 中的条目是设备节点。它们把文件描述符这套统一接口连接到内核驱动，但 “一切皆文件” 只是一条有用的近似，不是说设备节点等价于磁盘上的普通文件。

例如，读写块设备、终端和随机数设备的语义完全不同。有些设备主要通过 read、write 工作，有些依赖 ioctl，还有些根本不允许普通用户访问。现代发行版通常由 devtmpfs 和 udev 动态维护这里的内容。

/proc：进程视图与历史形成的内核接口#

procfs 最初围绕进程信息设计，因此 /proc/<pid> 暴露进程的状态、文件描述符、内存映射和命名空间。后来许多全局内核接口也进入 /proc，例如 /proc/cpuinfo、/proc/meminfo 和 /proc/sys。

它不是 “硬盘里恰好有很多零字节文件”。读取这些路径时，内核动态生成内容；写入某些路径时，内核把数据解释为控制请求。

/sys：按内核对象组织的设备模型#

sysfs 导出内核对象、属性以及对象之间的关系。设备、驱动、总线、类和固件信息因此有了比 /proc 更结构化的位置。

几个常见入口：

• /sys/class：按设备类别组织的视图，例如网络接口、LED 和 hwmon。
• /sys/bus：按总线组织设备与驱动。
• /sys/devices：设备拓扑。
• /sys/firmware/devicetree/base：设备树系统上，内核展开后的设备树视图。
• /sys/fs：cgroup、BPF、pstore 等文件系统或内核子系统的挂载入口。

sysfs 属性通常是稳定 ABI 的一部分，但并不意味着所有子目录都适合应用程序随意写入。例如旧的 sysfs GPIO 用户接口已经被内核文档标为废弃，新程序应优先使用 GPIO 字符设备接口。能 echo 1 不代表应该永远 echo 1，这是 Shell 最容易制造的乐观主义。

1. 这个路径来自什么文件系统？#

1
findmnt -T /
2
findmnt -T /proc
3
findmnt -T /sys
4
findmnt -T /run

关注 SOURCE、FSTYPE 和 OPTIONS。一台常见系统可能分别显示磁盘文件系统、proc、sysfs 和 tmpfs，但容器或不可变发行版会给出不同答案。findmnt 的输出比凭目录名猜测可靠。

2. /bin 还是真目录吗？#

1
readlink -f /bin
2
readlink -f /sbin
3
readlink -f /lib

这种布局称为 usr-merge（/usr 合并）：原本分散在根目录和 /usr 下的同类目录被合并到一起，文件统一放进 /usr/bin、/usr/sbin、/usr/lib，再让 /bin、/sbin、/lib 成为指向它们的符号链接。旧程序仍然可以访问 /bin/ls，系统实际执行的却与 /usr/bin/ls 是同一个文件。

早期系统把 /bin 和 /usr/bin 分开，是为了在 /usr 分区尚未挂载时，仍能依靠根分区里的少量工具启动和修复系统。现代 Linux 通常先进入 initramfs，由它准备存储设备并挂载真正的根文件系统，旧边界的实际价值已经很小。usr-merge 因此不是删除兼容路径，而是用符号链接保留旧接口，同时让发行版只维护一套系统文件。

运行上面的 readlink 命令，就能判断当前系统是否采用了这种布局。传统系统中的这些路径仍可能是彼此独立的目录。

3. 一个程序实际加载了哪些库？#

1
ldd /usr/bin/ls

输出会暴露动态加载器与架构相关库目录。在 Debian 的 Multiarch 系统上，你可能看到 /lib/x86_64-linux-gnu；采用 multilib 的系统则常见 /lib64。这是发行版 ABI 布局，不应该被简化成 “64 位系统一律使用 /lib64”。

4. 当前进程属于哪些命名空间？#

1
readlink /proc/self/ns/mnt
2
readlink /proc/self/ns/net
3
readlink /proc/self/ns/pid

输出类似 mnt:[4026531832]。两个进程对应条目的设备号和 inode 相同，才说明它们处在同一个该类型命名空间。方括号里的数字是 namespace inode，不是所谓的 “物理隔离宇宙哈希值”。

5. cgroup v2 怎样表达资源边界？#

1
findmnt -T /sys/fs/cgroup
2
cat /proc/self/cgroup

现代 cgroup v2 通常呈现一棵统一层级。控制器通过 cpu.max、memory.max 等接口设置限制，进程通过 cgroup.procs 加入 cgroup。Docker 和 Kubernetes 会使用这些内核机制，但 /sys/fs/cgroup 本身不属于 FHS 的文件放置规则。