采取 UsrMerge 措施的理由

openSUSE 已于近期开始对 /usr 合并措施的实验，openSUSE 中文社区从 freedesktop.org 翻译了这篇文章，旨在让用户了解这一改变。

译者为 Hanjingxue Boling，英语原文详见：The Case for the /usr Merge

采取 /usr 合并措施的理由

这篇文章是基于 Harald Hoyer 和 Kay Sievers 为同一主题所做的 Fedora 功能。这个功能已经在 Fedora 17 中成功实现。

为什么 /usr 合并（也称 usrmerge，/usr merge，UsrMerge）对兼容性来说是有意义的

/usr 合并（也称 usrmerge，/usr merge，UsrMerge）。请注意，本页面讨论的是一个实际上独立于systemd的话题。systemd 既支持分裂的系统，也支持合并的 /usr，而且 /usr 的合并对 systemd-less 的系统也有意义。我们希望鼓励采用 systemd 的发行版也采用 /usr 合并。

这里讨论的是什么？

Fedora（和其他发行版）已经完成了摆脱 /bin 和 /usr/bin ，以及 /sbin 和 /usr/sbin ，/lib 和 /usr/lib ，以及 /lib64 和 /usr/lib64 分离的工作。所有来自根目录的文件将被合并到 /usr 中的相应目录中，而旧目录的符号链接将被创建。

/bin   → /usr/bin
/sbin  → /usr/sbin
/lib   → /usr/lib
/lib64 → /usr/lib64

你想知道为什么将 /bin、/sbin、/lib、/lib64 合并到它们各自在 /usr 中的对应部分是有意义的，以及为什么发行版正在推动它？你想知道你自己的发行版是否应该采用同样的变化？下面是对这些问题的一些回答，重点是兼容性的观点：

关于兼容性：简短版本

• 改进了与其他 Unixes/Linux 的 行为 兼容。在 /usr 合并之后，所有的二进制文件都可以在 /bin 和 /usr/bin 中使用，或者在 /sbin 和 /usr/sbin 中使用（仅仅是因为 /bin 成为 /usr/bin 的符号链接，或者 /sbin 成为 /usr/sbin 的符号链接）。这意味着为其他 Unix 或其他 Linux 编写的脚本/程序被移植到你的发行版上时，将不再需要修正所调用的二进制文件的文件系统路径，否则这将是一个令人沮丧的主要来源。/usr/bin 和 /bin（即 /usr/sbin 和 /sbin ）变得完全等同。
• 改进了与其他 Unix 系统（特别是 Solaris ）在 外观 上的兼容性。现在主要的商业 Unix 实现是 Oracle Solaris 。Solaris 已经在 Solaris 11 中完成了同样的 /usr 合并。通过在 Linux 中做同样的改变，我们将与主要的 Unix 实现的差异降到最低，从而使 Solaris 的可移植性更容易。
• 改进与 GNU 构建系统的兼容性。绝大部分的 Linux 软件是用 GNU autoconf/automake（即 GNU autotools）构建的，它们不知道 Linux 特有的 /usr split。维护 /usr split 需要在上游构建系统和你的发行包中进行非复杂的项目特定处理。有了 /usr 合并，这些工作就变得没有必要了，而且将软件包移植到 Linux 也变得更加简单。
• 改善与当前上游开发的兼容性：为了尽量减少从你的 Linux 发行版到上游开发的差异，/usr 合并是关键。

关于兼容性：详细版本

因 /usr 合并产生的统一的文件系统布局比 Linux 传统的，分割的 /bin 与 /usr/bin 的文件系统与 UNIX 具有更好的兼容性。UNIX 在单个工具的安装位置上有所不同，它们的位置在许多情况下根本没有被定义，而且在不同的 Linux 发行版中也有所不同。/usr 合并完全消除了这种差异，并通过从 /bin 到 /usr/bin 的符号链接提供了与任何 Unix 的工具位置的完全兼容。

举例说明：

• /usr/bin/foo 可以被其他工具通过 /usr/bin/foo 或 /bin/foo 调用，这两个路径通过 /usr 合并变得完全等同。操作系统最终执行的是完全相同的文件，只是因为符号链接 /bin 将调用重定向到 /usr/bin 。

将 /bin、/sbin 和 /lib 与 /usr 分开的历史理由今天已不再适用。（详见更多关于分割的历史理由，由 Rob Landley 撰写）它们被分割开来，以便在更快的硬盘上选择工具（这块硬盘很小，因为它更昂贵），并包含所有必要的工具来挂载较慢的 /usr 分区。今天，一个独立的 /usr 分区已经必须在早期启动时被 initramfs 挂载，从而使分割的理由变得毫无意义。此外 /bin 和 /sbin 中的很多工具现在已经失去了在没有预先挂载的 /usr 的情况下运行的能力。再也没有正当的理由让操作系统分布在多个层次上了，/usr 分割已经失去了它的目的。

Solaris 在15年前就已经实现了 /usr 合并的核心部分，并在 Solaris 11 的发行中完成了这一工作。Solaris 的 /bin 和 /sbin 在根文件系统中只作为符号链接，与 /usr 合并后的方式相同：从 Oracle Solaris 10 过渡到Oracle Solaris 11 –用户环境功能变化。

不在你的发行版中实现 /usr 合并将使它与上游开发隔离。它将使软件包的移植出现不必要的困难，因为打包者需要将安装的文件分割成多个目录，并为工具硬编码不同的位置；这两者都将导致不必要的不兼容。一些 Linux 发行版赞同 /usr 合并的好处，并且已经处于实施 /usr 合并的过程中。这意味着上游项目将迅速适应这种变化，那些使移植到你的发行版上变得更加困难。

在兼容性之外

/usr 合并的一个主要好处是降低了我们系统的复杂性：新的文件系统层次结构变得更加简单，供应商提供的操作系统资源和用户资源之间的分离（只读，甚至可能是不可改变的）变得更加干净。由于层次结构的复杂性降低，打包也变得更加简单，因为处理 .spec 文件中的分割问题已经消失。

合并后的 /usr 目录几乎包含了所有供应商提供的操作系统资源，为我们提供了许多关于操作系统快照的新功能，并为企业环境提供了网络共享或在一台主机上运行多个客人的选择。静态的供应商提供的操作系统资源被限制在一个单一的位置，可以很容易地使其成为只读，无论是对整个系统还是对每个服务都是如此。在目前任意将工具分割到多个目录的情况下，这些大部分都更难完成，甚至不可能完成。

由于所有供应商提供的操作系统资源都在一个目录 /usr 中，它们可以被原子化地共享，它们的快照将原子化，而且文件系统可以作为单一的单元进行只读。

样例：/usr 网络分享

• 有了合并后的 /usr 目录，我们可以向网络提供一份供应商提供的操作系统的只读输出，这将包含几乎所有的操作系统资源。然后，客户主机将只需要一个最小的特定主机根文件系统，其符号链接指向共享 /usr 文件系统。从维护的角度来看，这是第一次在网络上共享操作系统开始变得有意义。如果没有合并的 /usr 目录（像传统的 Linux），我们每次只能共享操作系统的一部分，而不能共享位于根文件系统中的核心组件。因此，特定主机的根文件系统传统上需要大得多，不能在客户主机之间共享，并需要单独和经常更新。供应商提供的操作系统资源传统上最终会“泄漏”到特定主机的根文件系统中。

样例：同一主机上的多个客户机操作系统

• 有了合并后的 /usr 目录，我们可以提供与多个客户机操作系统共享的只读 /usr 目录，这将使客人的文件系统缩减到几 MB。每个客户机操作系统的主机专用部分与共享操作系统的比例几乎是最佳的。从长远来看，你的发行版中的分割工具所造成的维护负担，以及硬编码的偏离安装位置，将二进制文件和其他打包的文件分配到多个层次中，很可能比 /usr 合并本身造成的麻烦更大。

误解与事实

• 误解1：Fedora 是第一个实现 /usr 合并的操作系统。

  事实：Oracle Solaris 在15年前就已经部分实现了 /usr 合并，并在 Solaris 11 中完成。Fedora 只是紧随其后，它并不是先驱者。

• 误解2：Fedora 是唯一实现了 /usr 合并的 Linux 发行版。

  事实：其他多个 Linux 发行版也一直在朝着类似的方向努力。（译注：也包括我们 openSUSE）

• 误解3： /usr 的合并降低了与其他 Unix/Linux 的兼容性。

  事实：通过在 /usr/bin 和 /bin 中提供所有二进制工具（即 /usr/sbin + /sbin ），可以提高脚本中硬编码二进制路径的兼容性。当发行版A在 /usr/bin 中安装一个工具 “foo”，而发行版B在 /bin 中安装它，那么我们将在这两个地方提供它，从而与A和B都产生兼容性。

• 误解4：/usr 合并的唯一目的是为了看起来漂亮，而没有其他好处。

  事实：/usr 合并使得在主机和联网客户端之间以及主机和本地轻量级容器之间共享供应商提供的操作系统资源更加容易和原子化。对操作系统进行快照成为一个可行的选择。/usr 合并还允许使整个供应商提供的操作系统资源成为只读，以提高安全性和鲁棒性。

• 误解5：在你的发行版中采用 /usr 合并意味着为你的发行版的软件包维护者提供额外的工作。

  事实：当合并在其他发行版和上游实现时，不在你的发行版中采用 /usr 合并意味着更多的工作，采用它就很方便。

• 误解6：分裂的 /usr 是 Unix 的 “标准”，而合并的 /usr 则是 Linux 特有的。

  事实：在 SysV Unix 上，/bin 传统上是一个与 /usr/bin 的符号链接。在非SysV Unix 和 Linux 中，该目录的非符号链接版本是特定的。

• 误解7：在 /usr 合并之后，人们不能再挂载 /usr 只读，因为这在许多地区是常见的用法。

  事实：恰恰相反! 我们这样做的原因之一实际上是为了使只读的 /usr 更加彻底：整个供应商提供的操作系统资源可以变成只读的，也就是说，所有传统上存储在/bin、/sbin、/lib 中的东西在已经在 /usr 的基础上。

• 误解8：/usr 的合并将破坏我的旧安装，因为我的 /usr 在一个单独的分区上。

  事实：这是完全可以支持的，而且我们这样做的原因之一是为了使将 /usr 放在一个独立的分区中更加彻底。变化之处在于，在进入根文件系统之前，你需要用一个挂载 /usr 的 initrd 来启动。大多数发行版都依赖于 initrds ，所以实际上没有什么变化。

• 误解9：/usr 分割对于在根文件系统上有一个最小的救援系统，而在 /usr 上有其余的操作系统是很有用的。

  事实：在 Fedora 上，根目录已经包含 ~450MB。这已经是很长时间以来的最小值了，由于今天复杂的存储和网络技术，要再减少这个值是不现实的。事实上，自从initrds 被引入 Linux 后，initrd 接管了作为最小救援系统的角色，它只需要一个工作的启动加载器来启动，而不是一个完整的文件系统。

• 误解10：分割的 /usr 和不使用 initrd 的挂载的现状现在完全被支持，并且可以工作。

  事实：在跳转到根文件系统之前，没有 initrd 参与的分裂的 /usr 在很长一段时间内都不能正确工作。

• 误解11：与其把 / 合并到 /usr 中，不如把 /usr 合并到 / 中更有意义。

  事实：这将使供应商提供的操作系统资源和机器特定的资源之间的分离更加糟糕，从而使操作系统的快照和网络/容器共享变得更加困难和非原子性，并使根文件系统被大量的新目录所干扰。

如果这个页面没有回答您的问题，您可以继续阅读 Fedora 功能页面和 Lennart 的这封邮件。