Introduction to Hurd translators
Debian -- Debian GNU/Hurd --- Documentation

[ Ports ]
[ Debian GNU/Hurd ]
[ News ]
[ Configuration ]
[ Hurd CDs ]
[ Documentation ]
[ Development ]
[ Contact ]

Translators

Concept
Examples
Passive Translators, Active Translators
Managing Translators

Concept

Before we take a closer look at translators, let us consider regular
filesystems. A filesystem is a 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.

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 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
separately.

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 kernel's point of
view, they are just another user process. This means, translators can be run
by any user. You don't need root privileges 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.
Examples
Mount Points

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.
Device Files

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 separate 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.
Symbolic Links

A symbolic link can be seen as a translator. Accessing 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
passive 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.
Passive Translators, Active Translators

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.
Active Translators

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.
Passive Translators

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.
Managing Translators

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.
Examples

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!

