☰

带有 btrfs（SLES15）的非空挂载点：它们需要吗？

tag-icon • tag-icon mount btrfs suse
带有 btrfs（SLES15）的非空挂载点：它们需要吗？

我有多年的 UNIX 经验，但我认为我犯了一个致命的错误：

在启动过程中看到有关非空挂载点的消息，我趁机在将系统迁移到新环境时清理了它们。我启动了 SLES 救援系统，在 上挂载了根文件系统和基本系统结构 (proc、sys、dev) /mnt，然后执行chroot /mnt了mount -va。

一切看起来都很好，我调整了一些配置设置，并在卸载时检查了挂载点。例如： /var/cache已挂载，umount成功，但仍ll /var/cache显示非空挂载点，而文件系统显示未挂载。所以我删除了内容。

基本上，我对每个安装的文件系统重复这些步骤，然后离开环境chroot，卸载其余文件系统并重新启动。

不幸的是，系统无法启动，因为 GRUB 抱怨它找不到normal.mod。

那么这是 btrfs 子卷的一个功能吗？谁能解释一下发生了什么？

/etc/fstab

根据我的要求/etc/fstab，典型系统具有以下内容：

/dev/sys/root                              /            btrfs  defaults              0  0
/dev/sys/root                              /var         btrfs  subvol=/@/var         0  0
/dev/sys/root                              /usr/local   btrfs  subvol=/@/usr/local   0  0
/dev/sys/root                              /tmp         btrfs  subvol=/@/tmp         0  0
/dev/sys/root                              /srv         btrfs  subvol=/@/srv         0  0
/dev/sys/root                              /root        btrfs  subvol=/@/root        0  0
/dev/sys/root                              /opt         btrfs  subvol=/@/opt         0  0
UUID=9fd27493-d194-48ba-a4bc-3551123e0d3b  /home        xfs    defaults              0  0
/dev/sys/boot                              /boot        btrfs  defaults              0  0
UUID=0092-D1D5                             /boot/efi    vfat   utf8                  0  2
/dev/sys/root                              /.snapshots  btrfs  subvol=/@/.snapshots  0  0

答案1

工作原理

/dev/sys/root包含一个 Btrfs 文件系统。您的 中的几个条目将fstab其不同子卷挂载到不同的挂载点。

假设：Btrfs 文件系统中的默认子卷/dev/sys/root是/@，一旦将其挂载在/，就会挂载许多其他子卷在特定的安装点几乎没有意义，因为正确的（通常非空的）目录已经在您期望的位置。

（要查看默认子卷，请运行sudo btrfs subvolume get-default /。）

请阅读这是我的另一个答案并了解设备上的 Btrfs 目录（和子卷）树与操作系统中的目录结构之间的概念差异。如果没有这些知识，当前答案的其余部分可能会让您感到非常困惑。

如果默认子卷是/@，/@从 Btrfs 树中显示为/OS 树以及下面的一切. 这种安装独自的/@/var足以看到Btrfs 树中的目录，就像/var在 OS 树中一样。我的意思是，如果你尝试访问/var 前 /var然后安装

  • 操作系统将检查/var（操作系统的）是否为挂载点；如果不是；
  • 因此操作系统将检查/（操作系统的）是否为挂载点；它是并且与/@Btrfs 相关联；
  • 因此操作系统将显示操作系统的/@/varBtrfs 。/var

碰巧的是，/@/varBtrfs 是一个子卷。此外挂载subvol=/@/var在/var（操作系统）将使相同的目录显示为/var（操作系统）。具体来说，如果你现在访问，/var那么

  • 操作系统将检查/var（操作系统的）是否为挂载点；它是并且它与/@/varBtrfs 相关联；
  • 因此操作系统将向您显示/@/varBtrfs。

如果您卸载/var（操作系统），那么您将回到第一种情况。

因此，操作系统是否安装并不重要/var（实际上这并不重要，可能存在细微差别）。无论如何，您都会在操作系统中看到/@/varBtrfs 。/var

fstab您的安装子卷中的其他几个条目无论如何你都会看到它们。我真不明白这些条目的意义何在（也许某些我目前无法辨别的微妙之处才是重点；或者这些条目确实完全没有意义）。

比较一下：如果/var（操作系统）已安装，subvol=/var那么安装它是有意义的，因为/varBtrfs 不在/@Btrfs 之下，因此您无法仅通过安装操作系统/@的 Btrfs来访问它。/

你是如何打破它的

… 已挂载，umount成功，但仍ll …显示非空挂载点，而文件系统显示未挂载。所以我删除了内容。

正如我所说，您的fstab安装目录中的多个条目位于不同的子卷中，您无论如何都会看到它们。在这些情况下，通过umount删除之前看到的内容后再删除内容umount。您以为您删除了隐藏的、不相关的内容，但实际上您删除的是实际的重要内容。

但有两点不太合适：

  1. 您的示例挂载点是，据称您已卸载它；但您发布的中/var/cache却没有。/var/cachefstab
  2. 根据您fstab发布的内容，虽然/（操作系统的）来自/dev/sys/root，/boot（操作系统的）来自/dev/sys/boot。所描述的破坏机制不适用。然而，您声称“GRUB 抱怨它找不到normal.mod”，从中我推断您确实以某种方式破坏了 下的东西/boot。

因此我怀疑已发布的fstab（您将其描述为“典型系统所具有的”）不是精确的 fstab受影响的操作系统。我怀疑/boot它使用了与相同的文件系统/，并且不必要地挂载了，因此容易发生上述破坏情况。

相关内容