是否有任何理由在 systemd 系统上远离 fstab？

Question

我在 Arch Linux 系统上，这意味着 systemd。

在 systemd 中有用于挂载点的本地单元文件，扩展名为 .mount。我一直只使用/etc/fstab，这从来没有给我带来问题，因为 systemd 只是从中获取信息。但是现在我已经真正阅读了文档，我想知道是否应该更改为原生 systemd 单元文件。

Arch Wiki 建议没有任何好处，因为它说要fstab在初学者指南中填充您的内容。

Answer 1

从man systemd.mount本身：

表

挂载单元既可以通过单元文件配置，也可以通过 /etc/fstab（详见 fstab(5)）进行配置。/etc/fstab 中列出的挂载将在启动时和重新加载系统管理器的配置时动态转换为本机单元。通常，通过 /etc/fstab 配置挂载点是首选方法。有关转换的详细信息，请参阅 systemd-fstab-generator(8)。

请注意，某些功能仅适用于 fstab。例如，当 initrd 中的 systemd 用于挂载 /usr 文件系统以及 / 文件系统时。initrd 中的 systemd 读取 / 上的 etc/fstab 并查找 /usr 的条目。

它还允许您mount /mountpoint手动使用。 systemd您通常很乐意这样做，例如，当您卸载或挂载文件系统时，它会更新挂载单元的状态。

Answer 2

systemd 挂载点支持更灵活的配置，至少何时挂载每个点。这有时在网络安装等非常复杂的问题中很有用。

根据经验，除非您坚持配置一些复杂的行为（如果您曾经这样做过），否则您只需使用 fstab，然后尝试找到 systemd 解决方案。

Answer 3

我刚刚遇到了systemd.mount一个其他人没有提到的用例：对于包管理（例如RPM），这是避免grep/sed技巧弄乱/etc/fstab. 由于没有与grubbyfor真正等效的fstab东西，因此打包一个安装您所需内容的服务文件要容易得多。

至少对于 RPM，我还发现当 RPM 被删除时，卸载脚本甚至会自动卸载。

Answer 4

Systemd 是一个更好的挂载解决方案，因为它使您能够在挂载时暂存依赖项。

即：通过使用After=.mount 文件中的指令，您可以确保在首次连接 LUN 之前不会进行挂载。以下是我编写的用于自动安装远程存储的脚本的片段：

cat <<EOF> /etc/systemd/system/mnt-$ISCSIDISKMOUNTFOLDER.mount
[Unit]
Description=iSCSI Disk
After=connect-luns.service

[Mount]
What=/dev/disk/by-uuid/$(ls -al /dev/disk/by-uuid | grep $ISCSIDEVICE | awk '{print $9}')
Where=/mnt/$ISCSIDISKMOUNTFOLDER
Type=$FILESYSTEM

[Install]
WantedBy=multi-user.target

EOF

挂载是在服务“ connect-luns.service ”启动之前发生的，但是一旦我将服务插入After=指令，存储现在就会在启动时正确启动。Systemd 提供了一种非常简单且优雅的方法来管理在此用例中安装远程存储的依赖关系。

例外：

在某些情况下，您可能无法使用 SystemD 来挂载存储，一个非常显着的例外是Alpine Linux，它仍然使用 SysVinit 和/etc/fstab来维护小型配置文件。Alpine Linux 在容器领域很受欢迎。/etc/fstab所以，无论你信不信，即使是在 SystemD 载歌载舞的时代，仍然有一席之地。