1

I am trying to check for the current status of a mounted partition, rw/ro. On Cent6 /proc/self/mountinfo has some interesting info. One of the items contained in the output for each mount point is "mount options: per-mount options." the other one is "super options: per-super block options."

I am wondering how these compare to each other. I have read man pages till I am blue in the face and the animal book on Understanding The Linux Kernel. What I would like to know specifically is that if for some reason a drive all of a sudden because ro, Linux detects and issue and tried to protect itself, would the super options be changed as well, or would those reflect the original state of the drive? I am looking for an absolute way to test if a drive it rw according to the OS. Fstab won't work, and I have been reading not to trust mount, /proc/mounts was what I have been using as mountinfo is not available to be on my Cent5 boxes. I know I can just touch a file but I was looking for an OS level way, not a "user" level way. What I hoped was I could compare the mount-options and super-options and if they match good, if not fail.

I would also take any more reading tips, I have read through a fair amount of commit notes on mountinfo as well and some of the bug reports from Redhat about /proc/mounts which is what led me to mountinfo in the first place.

Thanks

Matty
  • 163
  • 1
  • 5
  • Where did you hear not to trust /proc/mounts? I'd love to know the source. – Matthew Ife Mar 11 '14 at 02:37
  • https://bugzilla.redhat.com/show_bug.cgi?id=491924 Not sure if it is relevant, I am still learning about this stuff and trying to look at all available resources. I am a coder by trade but working in monitoring so I have to be an admin of sorts as well. – Matty Mar 11 '14 at 02:39

1 Answers1

3

/proc/self/mountinfo is the most authoritative source to check your mounts.

/proc/mounts is a deprecated source to check the status of your mounts.

The reason (in the linked bug report) that it says to avoid using it, is that it doesn't produce extra info that might be important in certain scenarios (whether it is a shared mount, private, unbindable etc, which only applies when using mount namespaces) and as such is technically deprecated in favour or /proc/self/mountinfo.

This distinction is not relevant for older distros. EL5 for example does not completely support separate namespaces, so the case for /proc/self/mountinfo is not useful.

If you're really just interested in mount flags /proc/mounts is fine.

Note that /proc/mounts symlinks to /proc/self/mounts because the 'mount view' that the process sees is on a per-namespace basis and processes may be in different namespaces. For the vast majority of use-cases, this exception really shouldn't apply (you'd know if you were using mount namespaces).

ACyclic
  • 133
  • 4
Matthew Ife
  • 23,357
  • 3
  • 55
  • 72