There are many ways to fetch the list of currently-mounted-devices: read the files /etc/mtab, /proc/mounts, or exec /bin/mount, /bin/df.
I've been arguing with a colleague (Yaniv), that relying on /etc/mtab is no much worse than relying on /proc/mounts. But after we inspected it on Linux & Solaris (/etc/mnttab), I figured out that I was pretty wrong, and learned some new surprising facts:
On Linux:
- /proc/mounts is a read-only, kernel-generated file.
- /etc/mtab (Linux) is a regular file. It's kept up-to-date because the mount/umount commands modify it. It can be modified by a root user, moved and even deleted!
- df command is using /etc/mtab, thus after rm'ing /etc/mtab, df would stop functioning.
- mount command doesn't care about /etc/mtab, probably uses /proc/mounts or some internal kernel structure.
On Solaris (prepare for some weird stuff now):
- Solaris has got /etc/mnttab, but no /proc/mounts equivalent.
- /etc/mnttab is a mounted filesystem, of the mntfs type. So it's somewhat similar to /proc/mounts on Linux. It cannot be modified.
- /etc/mnttab is actually a directory! (a mount point has to be a directory..)
- /etc/mnttab can be unmounted, renamed, rmdir'd (when unmounted) and mounted anywhere else.
- both df and mount rely on /etc/mnttab, thus not functioning when it's absent
On HP-UX:
- /etc/mnttab, which is a regular file, is similar to /etc/mtab on Linux.
And on another, non-related subject: looks like Debian Lenny has got only 80 bugs to go (as of 19/01/09)! Go Lenny!
On Linux, /etc/mtab is used by grub-install script to detect the root disk (the one to install on its MBR). During P2V, changes to the disk structure (for example, from IDE to SCSI or vice versa) can cause grub setup issues due to this change.
Ez
■df command is using /etc/mtab, thus after rm’ing /etc/mtab, df would stop functioning.
■mount command doesn’t care about /etc/mtab, probably uses /proc/mounts or some internal kernel structure.
These 2 findings are really interesting and informative for me. Thanks Guys !!!!
-Ashok