Jde*_*eBP 59
% 文件 /etc/mtab /etc/mtab: ../proc/self/mounts 的符号链接 % 文件 /proc/mounts /proc/mounts: self/mounts 的符号链接 %
/etc/mtab是一种兼容机制。几十年前,Unix 没有读取现有挂载信息的系统调用。取而代之的是,安装文件系统的程序应该合作并自愿地维护一个/etc/mtab关于安装位置的表格。
出于显而易见的原因,这不是理想的机制。
Linux 获得了“procfs”的概念,它获得的其中一件事是该表的内核维护版本,以mounts伪常规文件的形式。从内核中读取挂载信息的“系统调用”变成了针对该文件的打开-读取-关闭序列,然后将结果从人类可读的形式解析为机器可读的形式(有一些微妙的问题,就像你可以从两周前的错误报告中看到)。
/etc/mtab因此已普遍成为 的符号链接/proc/mounts,允许硬连线该名称的程序继续从该文件读取挂载表,挂载和卸载文件系统的程序不再需要自己明确地做任何事情来保持最新状态。(不过,如果/etc/mtab结果是可写的常规文件,它们中的一些仍然会。并且有一些极端情况,其中mounts缺少所有非内核内容的规范化信息并不是所需要的;尽管它们并不重要的一般问题/etc/mtab。)
每个进程现在能有什么装的自己的个人观点,并有因此现在个人mounts在procfs的每个进程的文件,每个进程的自己的表通过为它访问self符号链接self/mounts,并且/proc/mounts是也目前兼容性机制。(有趣mounts的mounts是,当前的 Linux doco 中既没有记录每个进程,也没有记录 的格式,尽管类似的mountinfo伪常规文件是。)
SunOS/Solaris 具有类似的机制。该/etc/mnttab文件实际上是一个单文件文件系统,除了读取表外,通过对该文件的打开文件描述符,通过read()系统调用,您可以poll()使用ioctl().
在 HP-UX 中,/etc/mnttab它同样是文件名,但从版本 11 开始,它仍然是一个常规文件,其内容由系统实用程序共同维护。
AIX 不会导出程序必须解析的人类可读的文本表,并且没有等效文件。类似地,BSDgetfsstat()在 FreeBSD 和 OpenBSD 上具有成熟的系统调用,用于程序以机器可读的形式从内核获取挂载表,而无需通过人类可读的中间形式对其进行编组。
/proc/self/mountinfowith \r in mount path。#35137。GNU coreutils 错误。/proc/mounts. 文档/文件系统/proc.txt。Linux 5.1。fstab-decode。错误 #567071。Debian 错误。getfsstat(). FreeBSD 系统调用手册。2016-12-27。Chr*_*her 14
根据man mount:
程序 mount 和 umount 传统上在文件 /etc/mtab 中维护当前挂载的文件系统列表。这个真正的 mtab 文件仍然受支持,但在当前的 Linux 系统上,最好将其设置为 /proc/mounts 的符号链接,因为在用户空间中维护的常规 mtab 文件不能可靠地与命名空间、容器和其他高级 Linux 功能一起使用。
在没有记录的情况下安装/etc/mtab:
-n, --no-mtab
挂载而不写入 /etc/mtab。例如,当 /etc 位于只读文件系统上时,这是必需的。
手册页中给出了更多细微差别。