Linux文件系统中为什么有 /bin 和 /usr/bin、/lib 和 /usr/lib之分?
- 2026-02-02 21:04:00
- 丁国栋
- 原创 19
这个问题涉及到 Linux 文件系统发展的历史。简单来说,这种区分源于早期硬盘容量小、网络慢的“分体时代”,目的是为了允许系统核心在脱离 /usr 的情况下独立启动,并方便 /usr 通过网络被多台机器共享。
核心历史原因:UNIX 文件系统分层规范(FSSTND)
在 20 世纪 80-90 年代,磁盘空间(尤其是根分区)非常昂贵,网络带宽有限。为了解决这个问题,UNIX 社区(后来被 Linux 继承)制定了 FSSTND 规范,其核心思想是:
- 将操作系统分割为“启动运行必需的最小集”和“完整的系统软件集”。
- 允许
/usr目录(包含大部分用户程序和库)通过网络文件系统(NFS)挂载,被局域网内的多台计算机共享。
基于这个目标,目录被明确分工:
-
/(根分区):存放启动、修复系统所绝对必需的核心工具和库。/bin: 系统引导、在单用户模式(救援模式)下修复系统时必需的基本用户命令。例如:ls,cp,rm,mkdir,bash,cat等。没有这些命令,你甚至无法完成最基本的系统修复。/sbin: 系统引导、修复时必需的系统管理员命令。例如:init,ip,mount,fsck,ifconfig等。/lib: 为/bin和/sbin中的程序提供必需的共享库和内核模块。
-
/usr(通常是一个独立分区或网络挂载点): 存放所有非核心的应用程序、库、文档和数据,可以被安全地共享。/usr/bin: 非必需的用户应用程序。例如:gcc,vim,python,firefox等。在单用户模式下,这些程序不是必需的。/usr/sbin: 非必需的系统管理程序。/usr/lib: 为/usr/bin和/usr/sbin中的程序提供的库。
举个经典场景例子: 一台无盘工作站启动时,它首先从自己的引导介质(或网络)加载内核,挂载本地的 / 分区(很小),然后通过网络挂载服务器上的 /usr 分区。这样,一台服务器可以为一个实验室的所有机器提供相同的应用程序,节省了大量本地存储空间。
现代发展:合并趋势
随着时间的推移,硬盘变得又大又便宜,个人电脑和服务器通常都有完整的本地存储,无盘工作站和网络共享 /usr 的场景变得非常小众。这种历史性的分割带来了管理上的麻烦,比如用户经常困惑一个命令到底在 /bin 还是 /usr/bin。
因此,从 2011 年开始,以 Fedora 为首的主流 Linux 发行版推动了一项变革,并最终形成了 “merged-usr”(或称为 usrmerge) 布局。其核心变化是:
/bin和/lib不再是独立的目录,而是分别变成了指向/usr/bin和/usr/lib的符号链接。/sbin和/lib64同理,指向/usr/sbin和/usr/lib64。
目的:
- 简化文件系统层次结构,消除用户的困惑。
- 统一应用程序和库的存放位置,方便包管理。
- 兼容性:所有期望在传统路径找到程序的脚本和软件仍然可以正常工作,因为符号链接是透明的。
现在的主流状况:
- 大多数现代发行版(如 Debian 及其衍生版 Ubuntu、Fedora、Arch Linux、openSUSE 等)已经默认采用“merged-usr”布局。
-
如果你在新系统上执行
ls -l /,你很可能会看到:lrwxrwxrwx 1 root root 7 Jan 1 2023 bin -> usr/bin lrwxrwxrwx 1 root root 7 Jan 1 2023 lib -> usr/lib lrwxrwxrwx 1 root root 7 Jan 1 2023 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 8 Jan 1 2023 sbin -> usr/sbin
对比
| 传统分割布局 (历史原因) | 现代合并布局 (当前主流) |
|---|---|
/bin: 核心命令,独立分区 |
/bin -> /usr/bin (符号链接) |
/sbin: 核心管理员命令 |
/sbin -> /usr/sbin |
/lib: 核心库 |
/lib -> /usr/lib |
/usr/bin: 用户应用程序,可共享 |
/usr/bin: 所有用户命令 |
/usr/lib: 应用程序库 |
/usr/lib: 所有库文件 |
所以,现在 /bin 和 /usr/bin 的区分主要是为了向后兼容和历史延续。在新系统中,它们在物理上通常是同一个目录,只是通过符号链接提供了两个访问路径。 这也符合 Linux 文件系统设计的哲学——实用主义,以及在约束条件下解决问题的智慧。
参考: