将 /usr/bin 和 /usr/sbin 合并到 /bin (GNU/Linux)

将 /usr/bin 和 /usr/sbin 合并到 /bin (GNU/Linux)

我读过很多关于人们想要将 /bin 和 /sbin 合并到 /usr/bin 的讨论。反过来做就不能说同样的事情了。

是否有任何技术原因导致人们不想将 /usr/bin 和 /usr/sbin 合并到 /bin 中,或者这主要是个人喜好/设计选择?

答案1

将内容合并到 /usr 而不是 / 的原因在/usr 合并案例:

误区#11:与其将 / 合并到 /usr 中,不如将 /usr 合并到 / 中更有意义。

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

答案2

你是对的,Fedora 是这方面的前卫,尽管自由桌面网站一个独立机构随后开始了这项事业,希望能够鼓励泛 Linux。

根据,合并遵循 Solaris(“主要商业 Unix 实现”)启动的模式。有趣的是,原始 Unix 使用/bin,因此摆脱分割可能意味着在/usr符号链接中创建目录,而不是相反。

然而,考虑到这个选项,链接顶层可能更直接、更明显。

答案3

/sbin 和 /usr/sbin 历史上是保存静态链接二进制文件的地方。 /sbin 用于 init 级别 1(单用户模式)所需的管理级命令,/usr/sbin 用于 init 级别 3 所需的更常规管理命令(完全联网、启用远程登录、启用 NFS)。不幸的是,Linux 不再采用这种模型。

答案4

作为一名系统工程师,我发现这种趋势令人遗憾。例如,闪存具有非常快的访问速度,但它也很昂贵(每 GB 成本比旋转磁盘介质高出 3 倍),并且存在的问题是,在内存位中的静电荷积累使设备无法正常工作之前,您只能写入这么多数据。不可用(首先由设备固件纠正软错误,然后是硬错误,此时设备将自身标记为只读)。

所以,我们仍然有“快速、昂贵的内存”和“慢速、便宜的内存”

即使在 Raspberry Pi 上,我也更喜欢将一个小型 2.5 英寸磁盘(笔记本电脑大小)连接到 USB 3.0 端口,将所有必要的启动相关内容放在 /bin 上,以及所有非必要的( USER! ) 在 /usr 和有大量写入活动的地方,例如 /tmp 和 /var/tmp,特别是 /var/log 和 /var/cache...在更便宜、更耐用的 1TB 2.5" 磁盘上,因为这些子树会不断被写入。当我设置一个系统时,我通常会创建一些文件系统,正是为了将高写入量子树与中等写入量子树以及低写入量子树和用户帐户文件系统(/home 或其他)隔离开来。 ) 与 /var/log 分开。

/opt 可以成为指向 /usr/_opt 的指针(我使用前缀和中缀 _ 字符作为符号链接目标来指示符号链接来自何处。因此 /opt 成为指向 /usr/_opt 的符号链接。 /tmp成为 /mnt/highwrites/_tmp 的符号链接,而 /var/tmp 成为 /mnt/highwrites/_var_tmp 的符号链接,这样,我不必猜测哪个“tmp”目录将需要更多。空间...它们都位于同一文件系统上,并且其频繁且大量的写入与所有其他文件系统安全隔离。当出现问题时...在什么时候?那时你真的不希望太多(或者理想情况下任何)文件系统写入根文件系统。

合并 /usr 和 / 始终是一个愚蠢的计划,尽管我非常钦佩 Sun Microsystems 及其历史,但我真的不在乎 Sun 是否开始了这种疯狂。最重要的已安装太阳能系统足够昂贵且足够重要,以至于它们拥有每天使用的充足的系统备份资源。一般的linux系统没有这样的资金投入,尤其是家庭和小型企业用户。

因此,默认配置应该在安全方面犯错误,并通过分离出在其自己的文件系统上活动最多的目录来隔离大多数文件系统写入,从而最大限度地减少数据丢失,而不是统一整个文件系统并将问题传播到最有价值的文件(1.用户数据,其次是系统启动和损坏评估和修复所需的可执行文件和目录(fsck、转储和恢复类型程序,以及存储硬件故障时的 mkfs、mkswap 和一些文件)其他有用的程序,如 grep 等,当然还有所有硬件和一些虚拟(如 RAID)设备驱动程序)

用户态应用程序的升级和错误修复往往比传统上位于 /bin 和 /sbin 中的“系统必需品”要频繁得多。保持文件系统较小且很少写入可以减少损坏的机会。我不太关心传统上在 /usr 中找到的东西是否被损坏,但我绝对关心 mount 和 fsck 是否位于被损坏的文件系统上。

即使您使用单一存储技术(例如单个 1 TB 硬盘),将 /usr 放在单独的分区上仍然更有意义,原因很简单,即保持根分区尽可能小,写入次数也尽可能少尽可能。

至于“尽快安装东西”......大多数启动配置,一旦加载内核, / 文件系统就会被 fsck 并然后安装......然后是 fsck 并安装每个其他文件系统fstab 配置为在启动时安装,因此“更快的可用性”不是问题。此外,连续 fsck 的 10 个小文件系统可以比单个文件系统更快地进行 fsck,因为读写头的来回磁头移动保持在较窄的范围内,从而使寻头持续时间更短,其次通过稍长的磁头查找到下一个分区,而覆盖整个单个磁盘的文件系统可以从内部磁道到较远的外部磁道并返回数千次。

将单个磁盘划分为多个文件系统的唯一真正缺点是,如果您在第一个和最后一个分区上进行大部分写入活动,而不是在中间的一系列分区上,并且当磁盘从如果将一个分区上的文件系统转移到另一个分区上的文件系统,则与全部位于统一的单个文件系统中相比,它必须遍历更多的空块。

总而言之,单个文件系统的优势仍然比不上将单个存储设备划分为多个文件系统的优势。从可靠性和数据安全方面来看,多个文件系统(每个文件系统位于其自己的设备上)是首选(尽管最昂贵)的方法。当并行 SCSI 还很常见时,我曾经以便宜的价格购买二手 SCSI 磁盘...一张用于 /,一张用于 /usr,一张用于 /home,最小的(通常是最旧的)用于 /tmp、/var/tmp和/var/log。该设备通常是最小的,并且最有可能发生故障,其文件的价值相对较低(程序不会将结果存储在 /tmp 中,除非用户这样指定......所以 /tmp 和 /var/tmp 具有一次性的数据,因为它们是“暂存器”区域,并且单个 /tmp 目录可以通过 NFS 被多个主机共享。 /var/tmp 用于无法位于共享 /tmp 上的 tmp 文件。

Poettering 确实试图将 Linux 简化为 MS-WINTENDO。

相关内容