What is /etc/mtab in Linux?

Why is it needed and advantages of having it?

According to man mount:

The programs mount and umount traditionally maintained a list of currently mounted filesystems in the file /etc/mtab. This real mtab file is still supported, but on current Linux systems it is better to make it a symlink to /proc/mounts instead, because a regular mtab file maintained in userspace cannot reliably work with namespaces, containers and other advanced Linux features.

On mounting without recording in /etc/mtab:

-n, --no-mtab

Mount without writing in /etc/mtab. This is necessary for example when /etc is on a read-only filesystem.

Many more nuances are given in the manual page.

% file /etc/mtab
/etc/mtab: symbolic link to ../proc/self/mounts
% file /proc/mounts
/proc/mounts: symbolic link to self/mounts
%

/etc/mtab is a compatibility mechanism. Decades ago, Unix did not have a system call for reading the existing mount information. Instead, programs that mounted filesystems were expected to coöperatively and voluntarily maintain a table in /etc/mtab of what was mounted where.

For obvious reasons, this was not an ideal mechanism.

Linux gained the notion of a "procfs", and one of the things that it gained was a kernel-maintained version of this table, in the form of a mounts pseudo-regular file. The "system call" to read the mount information out of the kernel became an open-read-close sequence against that file, followed by parsing the result from human-readable to machine-readable form (something that has some subtle catches, as you can see from the bug reports from just over a fortnight ago).

/etc/mtab thus has popularly become a symbolic link to /proc/mounts, allowing programs that had hardwired that name to keep reading a mount table from that file, which the programs that mounted and unmounted filesystems no longer have to explicitly do anything themselves to keep up to date. (Some of them still will, though, if /etc/mtab turns out to be a writable regular file. And there are a few corner cases where the normalized information in mounts that lacks all non-kernel stuff is not quite what is needed; although they do not outweigh the general problems with /etc/mtab.)

Each process can nowadays have its own individual view of what is mounted, and there are as a consequence now individual mounts files for each process in the procfs, each process's own table being accessible to it via the self symbolic link as self/mounts, and /proc/mounts is also now a compatibility mechanism. (Interestingly, neither per-process mounts nor the format of mounts are documented in the current Linux doco, although the similar mountinfo pseudo-regular file is.)

SunOS/Solaris has a similar mechanism. The /etc/mnttab file is actually a single-file filesystem, and in addition to reading the table, via an open file descriptor to that file, with the read() system call, one can watch for mount point changes with poll() and obtain various further pieces of information with ioctl().

In HP-UX, /etc/mnttab is likewise the name of the file, but as of version 11 it was still a regular file whose contents were coöperatively maintained by the system utility programs.

AIX does not export a human-readable text table that programs have to parse, and there is no equivalent file. The BSDs, similarly, have fully-fledged system calls, getfsstat() on FreeBSD and OpenBSD, for programs to obtain the mount table from the kernel in machine-readable form without marshalling it through a human-readable intermediate form.

Further reading

• Zygmunt Krynicki (2019-03-16). r in path confuses mount units. #12018. systemd issues.


• Zbigniew Jędrzejewski-Szmek (2019-04-04). [df] incorrect parsing of /proc/self/mountinfo with r in mount path. #35137. GNU coreutils bugs.


• 
  getfsstat(). FreeBSD System Calls Manual. 2016-12-27.