Proposal: a consistent mount interface

Maciej Stachowiak (mstachow@mit.edu)
Tue, 26 Nov 1996 06:51:01 EST

Examining the kernel code for the various filesystems as well as the
code for the standard mount utilitites, I have found what I think is a
potentially annoying problem. The vast majority of linux filesystems
have a standardized format for mount options, which is essentially a
comma-separated list of entries of the form 'option' or
'option=value'. The glaring exception is network filesystems which
take a variety of structures. Thus, the standard linux mount program
can deal with most non-networked filesystems directly, but network
filesystems must either be special-cased by the standard mount, as is
the case with nfs, or have special mount programs of their own, as is
the case which smbfs and ncpfs. Both approaches have disadvantages. It
is obviously impractical and foolish to have to add a special case to
the mount program any time someone comes up with a new filesystem that
wants an unusual mount structure. On the other hand, if the standard
mount program can't handle it, then you can't put it in your
/etc/fstab file, and /etc/fstab is a very useful abstraction for
reasons I'm sure I don't need to go into. Here are two proposed
solutions:

1) Have every filesystem in the kernel take a string of options in the
[option[=value](,option[=value])*] format as the data argument to
mount, rather than custom structures. Then a standard mount program
would work for all file systems without having to special-case
anything. Any information that you may want to pass to a filesystem at
mount time can almost certainly be passed to the kernel in this
format.

2) Do it like BSD: let every filesystem type take options in whatever
format it wants, and have a corresponding mount_fstype program for
each type. Then mount could simply be a wrapper that would invoke the
correct mount_fstype (or perhaps mount.fstype to go with the naming
convention for the various fsck programs). This would allow for
filesystems that need all sorts of odd things done at runtime, such as
have a particular daemon invoked or have parts of the mount data
structure that can only be generated at mount time.

The second solution is not, strictly speaking, a kernel
issue. However, I bring it up in this forum anyway, since special
mount programs would probably be written by the same people who write
kernel filesystems.

I personally like the first solution better, since it is much simpler.
Since mount(2) is linux-specific anyway, the last argument could
even be changed from void *data to char *data or something like that.

However, the second solution does have some advantages. Here they are,
along with my objections to them. First, it allows arbitrary
interesting things to be done in user space at mount time. However,
using kerneld, this can be achieved anyway. Second, if each fs type
had its own mount.fstype program, its mount options would be
documented in a separate man page. However, this really should be done
anyway, say in section 5 of the manual, or perhaps section 9. Finally,
sepcial-purpose mount programs allow you to pass a struct to the
kernel with all the options neatly aranged and with no need to parse
them. But I haven't seen any mount options where parsing would be
prohibitively expensive.

So what do people think?

- Maciej Stachowiak