[ale] /etc/mtab

[Michael Trausch]

On Wed, 2010-05-05 at 19:23 -0400, David Tomaschik wrote:
> Oddly enough, /proc/mounts doesn't retain all the information that
> mtab does.  For example, the kernel is oblivious to certain mount
> options that are only used by the mount.* program (e.g., credentials
> for CIFS).  I'm not sure how much of this still applies, but there's
> an extensive LKML thread[1] that documents this and the reasons for
> NOT making it a symlink to /proc/mounts.

It kind of looks to me like the issue was dropped without ever truly
resolving it.  Is /etc/mtab a hackish way of doing things?  Absolutely;
by now all of us programmers know not to repeat ourselves if we don't
have to.  And in this case, we shouldn't have to.

It really does look to me like there were a number of completely viable
solutions that were presented but never really seriously looked at.
Looking at it from the POV of both a programmer and a sysadmin, it seems
that having the information in /proc is the right thing to do: /proc is
maintained by the kernel, and the kernel is what manages filesystem
mount points.

With the recent addition of LXC in the kernel and the importance of
being able to maintain containerized views of things like that, I'd
personally think that two changes should be made:

 * Filesystems should be able to report back what filesystem-specific
   mount options are in effect for a given mountpoint.  This be
   relatively easy to implement, since there is already a means for
   the kernel to communicate with the filesystem driver to look up
   inodes and all of that.  So, the only additional requirement that
   this would have for filesystems is an entrypoint that returns
   the filesystem options as a set of (name, value) pairs.

 * The options that "mount" currently uses for itself should be
   registered with the kernel, perhaps by writing a set of
   null-separated (name, value) pairs to a file in /proc or by
   passing them to the mount system call; either way, since the
   mount utility is going to be Linux-specific, I don't see any real
   reason that it wouldn't be possible to do that.  Perhaps even by
   introducing a new system call and deprecating the old one, issuing
   a warning in the kernel ring buffer and /proc/kmsg when the
   deprecated one is used.

Then all of the available information would be present in /proc/mounts
when desired (or if they *really* wanted to make it separate, they could
do it in a new /proc/mtab or whatever, but I think that would just be
silly).

It would seem to me, that both of those changes would solve the problem
of having to have an /etc/mtab at all, except perhaps as a symlink.

Oh, well.  I'm just me, and it's just my thoughts.  It's likely that
it'll stay just the way it is, "for historical reasons".

	--- Mike

-- 
Even if their crude and anticompetitive business practices don't make
you think about using their software, their use of sweatshops and child
labor should:  boycott Microsoft like you would any other amoral child
abuser:  http://is.gd/btW8m

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20100505/6757c2ac/attachment.bin