[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]

[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled
[[GNU_Free_Documentation_License|/fdl]]."]]"""]]

[[meta title="mtab"]]

In traditional monolithic system, the kernel keeps track of all mounts; the
information is available through `/proc/mounts` (on Linux at least), and in a
very similar form in `/etc/mtab`.

The Hurd on the other hand has a totally
[[decentralized_file_system|hurd/virtual_file_system]].  There is no single
entity involved in all mounts.  Rather, only the parent file system to which a
mountpoint ([[hurd/translator]]) is attached is involved.  As a result, there
is no central place keeping track of mounts.

As a consequence, there is currently no easy way to obtain a listing of all
mounted file systems. This also means that commands like `df` can only work on
explicitely specified mountpoints, instead of displaying the usual listing.

One possible solution to this would be for the translator startup mechanism to
update the `mtab` on any `mount`/`unmount`, like in traditional systems.
However, there are some problems with this approach.  Most notably: what to do
with passive translators, i.e., translators that are not presently running, but
set up to be started automatically whenever the node is accessed?  Probably
these should be counted among the mounted filesystems; but how to handle the
`mtab` updates for a translator that is not started yet?  Generally, being
centralized and event-based, this is a pretty unelegant, non-hurdish solution.

A more promising approach is to have `mtab` exported by a special translator,
which gathers the necessary information on demand.  This could work by
traversing the tree of translators, asking each one for mount points attached
to it.  (Theoretically, it could also be done by just traversing *all* nodes,
checking each one for attached translators.  That would be very inefficient,
though.  Thus a special interface is probably required, that allows asking a
translator to list mount points only.)

There are also some other issues to keep in mind.  Traversing arbitrary
translators set by other users can be quite dangerous -- and it's probably not
very interesting anyways what private filesystems some other user has mounted.
But what about the global `/etc/mtab`?  Should it list only root-owned
filesystems?  Or should it create different listings depending on what user
contacts it?...

That leads to a more generic question: which translators should be actually
listed?  There are different kinds of translators: ranging from traditional
filesystems ([[disks|hurd/libdiskfs]] and other actual
[[stores|hurd/translator/storeio]]), but also purely virtual filesystems like
[[hurd/translator/ftpfs]] or [[hurd/translator/unionfs]], and even things that
have very little to do with a traditional filesystem, like a
[[gzip_translator|hurd/translator/storeio]],
[[mbox_translator|hurd/translator/mboxfs]],
[[xml_translator|hurd/translator/xmlfs]], or various device file translators...
Listing all of these in `/etc/mtab` would be pretty pointless, so some kind of
classification mechanism is necessary.  By default it probably should list only
translators that claim to be real filesystems, though alternative views with
other filtering rules might be desirable.

After taking decisions on the outstanding design questions, the student will
implement both the actual [[mtab_translator|hurd/translator/mtabfs]], and the
necessery interface(s) for gathering the data.  It requires getting a good
understanding of the translator mechanism and Hurd interfaces in general.

Possible mentors: Olaf Buddenhagen (antrik)

Exercise: Make some improvement to any of the existing Hurd translators.
Especially those in [hurdextras](http://www.nongnu.org/hurdextras/) are often
quite rudimentary, and it shouldn't be hard to find something to improve.