Before we take a closer look at translators, let us consider regular filesystems. A filesystem is store for a hierarchical tree of directories and files. You access directories and files by a special character string, the path. Furthermore, there are symbolic links to refer to one file at several places in the tree, there are hard links to give one and the same file several names. There are also special device files for communication with the hardware device drivers of the kernel, and there are mount points to include other stores in the directory tree. Then there are obscure objects like fifos and hard links.
Although these objects are very different, they share some common properties, for example, they have all an owner and a group associated with them as well as access rights (permissions). This information is written in inodes. This is a actually a further commonality: Every object has exactly one inode associated with it (hard links are somewhat special as they share one and the same inode). Sometimes, the inode has further information stored in it. For example, the inode can contain the target of a symbolic link.
However, these commonalities are usually not exploited in the
implementations, despite the common programming interface to them. All
inodes can be accessed through the standard POSIX calls, for example
read() and write(). For example, to add a new
object type (for example a new link type) to a common monolithic unix
kernel, you would need to modify the code for each filesystem
seperately.
In the Hurd, things work differently. Although in the Hurd a special filesystem server can exploit special properties of standard object types like links (in the ext2 filesystem with fast links, for example), it has a general interface to add such features without modifying existing code.
The trick is to allow a program to be inserted between the actual content of a file and the user accessing this file. Such a program is called a translator, because it is able to process the incoming requests in many different ways. In other words, a translator is a Hurd server which provides the basic filesystem interface.
Translators have very interesting properties. From the kernels point of view, they are just another user process. This means, translators can be run by any user. You don't need root priviligies to install or modify a translator, you only need the access rights for the underlying inode the translator is attached to. Many translators don't require an actual file to operate, they can provide information by their own means. This is why the information about translators is stored in the inode.
Translators are responsible to serve all file system operations that involve
the inode they are attached to. Because they are not restricted to the usual
set of objects (device file, link etc), they are free to return anything
that makes sense to the programmer. One could imagine a translator that
behaves like a directory when accessed by cd or
ls and at the same time behaves like a file when accessed by
cat.
A mount point can be seen as an inode that has a special translator attached to it. Its purpose would be to translate filesystem operations on the mount point in filesystem operations on another store, let's say, another partition.
Indeed, this is how filesystems are implemented under the Hurd. A filesystem is a translator. This translator takes a store as its argument, and is able to serve all filesystem operations transparently.
There are many different device files, and in systems with a monolithical kernel, they are all provided by the kernel itself. In the Hurd, all device files are provided by translators. One translator can provide support for many similar device files, for example all hard disk partitions. This way, the number of actual translators needed is quite small. However, note that for each device file accessed, a seperate translator task is started. Because the Hurd is heavily multi threaded, this is very cheap.
When hardware is involved, a translator usually starts to communicate with
the kernel to get the data from the hardware. However, if no hardware access
is necessary, the kernel does not need to be involved. For example,
/dev/zero does not require hardware access, and can therefore
be implemented completely in user space.
A symbolic link can be seen as a translator. Accesing the symbolic link would start up the translator, which would forward the request to the filesystem that contains the file the link points to.
However, for better performance, filesystems that have native support for symbolic links can take advantage of this feature and implement symbolic links differently. Internally, accessing a symbolic link would not start a new translator process. However, to the user, it would still look as if a passive translator is involved (see below for an explanation what a passsive translator is).
Because the Hurd ships with a symlink translator, any filesystem server that provides support for translators automatically has support for symlinks (and firmlinks, and device files etc)! This means, you can get a working filesystem very fast, and add native support for symlinks and other features later.
There are two types of translators, passive and active. They are really completely different things, so don't mix them up, but they have a close relation to each other.
An active translator is a running translator process, as introduced above.
You can set and remove active translators using the
settrans -a
command. The -a option is necessary to tell
settrans that you want to modify the active translator.
The settrans command takes three kind of arguments. First, you
can set options for the settrans command itself, like
-a to modify the active translator. Then you set the inode you
want to modify. Remember that a translator is always associated with an
inode in the directory hierarchy. You can only modify one inode at a time.
If you do not specify any more arguments, settrans will try to
remove an existing translator. How hard it tries depends on the force
options you specify (if the translator is in use by any process, you will
get "device or resource busy" error message unless you force it to go away).
But if you specify further arguments, it will be interpreted as a command
line to run the translator. This means, the next argument is the filename of
the translator executable. Further arguments are options to the translator,
and not to the settrans command.
For example, to mount an ext2fs partition, you can run
settrans -a -c /mnt /hurd/ext2fs /dev/hd2s5. The
-c option will create the mount point for you if it doesn't
exist already. This does not need to be a directory, by the way. To unmount,
you would try settrans -a /mnt.
A passive translator is set and modified with the same syntax as the active
translator (just leave away the -a, so everything said above is
true for passive translators, too. However, there is a difference: passive
translators are not yet started.
This makes sense, because this is what you usually want. You don't want the partition mounted unless you really access files on this partition. You don't want to bring up the network unless there is some traffic and so on.
Instead, the first time the passive translator is accessed, it is automatically read out of the inode and an active translator is started on top of it using the command line that was stored in the inode. This is similar to the Linux automounter functionality. However, it does not come as an additional bonus that you have to set up manually, but an integral part of the system. So, setting passive translators defers starting the translator task until you really need it. By the way, if the active translator dies for some reason, the next time the inode is accessed the translator is restarted.
There is a further difference: active translators can die or get lost. As
soon as the active translator process is killed (for example, because you
reboot the machine) it is lost forever. Passive translators are not transient
and stay in the inode during reboots until you modify them with the
settrans program or delete the inodes they are attached to.
This means, you don't need to maintain a configuration file with your mount
points.
One last point: Even if you have set a passive translator, you can still set a different active translator. Only if the translator is automatically started because there was no active translator the time the inode was accessed the passive translator is considered.
As mentioned above, you can use
settrans
to set and alter passive and active translators. There are a lot of options
to change the behaviour of settrans in case something goes
wrong, and to conditionalize its action. Here are some common usages:
settrans -c /mnt /hurd/ext2fs /dev/hd2s5 mounts a
partition, the translator will stay across reboots.settrans -a /mnt /hurd/ext2fs ~/dummy.fs mounts a
filesystem inside a data file, the translator will go away if it dies.settrans -fg /nfs-data forces a translator to go away.
You can use the showtrans
command to see if a translator is attached to an inode. This will only show
you the passive translator though.
You can change the options of an active (filesystem) translator with
fsysopts without actually restarting it. This is very
convenient. For example, you can do what is called "remounting a
partition read-only" under Linux simply by running fsysopts
/mntpoint --readonly. The running active translator
will change its behaviour according to your request if possible.
fsysopts /mntpoint without a parameter shows you the current
settings.
I recommend that you start by reading the /bin/mount command,
it is only a small script. Because setting filesystem translators is
similar to mounting partitions, you can easily grasp the concept this way.
Make a file system image with dd if=/dev/zero of=dummy.fs bs=1024k
count=8; mke2fs dummy.fs and "mount" it with settrans -c dummy
/hurd/ext2fs `pwd`/dummy.fs. Note that the translator is not started
yet, no new ext2fs process is running (verify with ps
Aux). Check that everything is correct using showtrans
Now type ls dummy and you will notice the short delay that
occurs while the translator is started. After that, there will be no more
delays accessing dummy. Under Linux, one would say that you automounted a
loop file system. Check with ps Aux that there is an ext2fs
dummy process up and running now. Now put some files into the new
directory. Try to make the filesystem read-only with fsysopts.
Note how further write attempts fail now. Try to kill the active translator
with settrans -g.
You should have some understanding of what is going on now. Now remember
that this was only one special server, the Hurd ext2fs server.
There are many more server in the hurd directory. Some of them
are for filesystems. Some are needed for file system features like links.
Some are needed for device files. Some are useful for networking. Imagine
"mounting" an FTP Server with settrans and downloading files
simply with the standard cp command. Or editing your web sites
with emacs /ftp/homepage.my.server.org/index.html!