Messages in this thread |  | | From | Maciej Stachowiak <> | Subject | Proposal: a consistent mount interface | Date | 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
|  |