是否有任何理由放弃 systemd 系统上的 fstab?

是否有任何理由放弃 systemd 系统上的 fstab?

我使用的是 Arch Linux 系统,这意味着 systemd。

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

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

答案1

man systemd.mount自身来看:

系统表

挂载单元可以通过单元文件或 /etc/fstab 进行配置(有关详细信息,请参阅 fstab(5))。 /etc/fstab 中列出的挂载将在启动时和重新加载系统管理器的配置时动态转换为本机单位。一般来说,通过 /etc/fstab 配置挂载点是人类管理挂载的首选方法。对于工具,编写挂载单元应该优先于编辑 /etc/fstab。有关从 /etc/fstab 到挂载单元转换的详细信息,请参阅 systemd-fstab-generator(8)。

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

它还允许您mount /mountpoint手动使用。 systemd通常很高兴您这样做,例如,当您卸载或安装文件系统时,它将更新安装单元的状态。

答案2

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

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

答案3

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

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

答案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

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

例外:

在某些情况下,您可能无法使用 SystemD 来安装存储,一个非常值得注意的例外是阿尔卑斯Linux它仍然使用 SysVinit 和 an/etc/fstab来保持一个小的配置文件。 Alpine Linux 在容器领域很受欢迎。所以,/etc/fstab无论你信不信,即使是在 SystemD 载歌载舞的时代,仍然有一席之地。

相关内容