Weekly Edition
Return to the Kernel page
| |||||||||||||
Trapfs - an automounter on the cheap
An automounter implements a special filesystem which mounts remote
filesystems on demand, when requested by a user-space process. The Linux
automounter (autofs) is a mildly complicated subsystem; the autofsNG patches make it somewhat more
complicated yet. Adam Richter decided that he could make things simpler,
and solve a wider class of problems at the same time. The result has been
recently posted as trapfs, a filesystem
which can do automounts and more in less than 500 lines.
Trapfs is derived from ramfs; by itself, it implements a simple, memory-based filesystem. A user-space process can create files, directories, device nodes, etc. in a trapfs filesystem, and everything will work as expected. There is one additional little twist, however: a trapfs filesystem can be mounted with the location of a special helper program given as a parameter. Whenever an attempt is made to look up a nonexistent file, the helper program is invoked and given a chance to cause that file to exist. When the helper exits, trapfs will return whatever the helper left behind to the original caller. So, if you want to implement an automounter, you just set up a trapfs filesystem with a little script which can figure out which remote filesystem to mount in response to a lookup request. The task can be done with a screenfull of commands - especially if security is not a big concern. Of course, there are some little details (such as unmounting idle filesystems) which are left as an exercise for the reader, but the basic idea is straightforward. Another possibility is to use trapfs to create a devfs-style device filesystem. The helper program responds to lookup requests by seeing if an appropriate device node can be created. Whether trapfs will prove useful for real-world tasks remains to be seen. It could have a role, however, in the creation of simple, dynamic filesystems in cases where a more complete solution (using FUSE, for example) is more work than is justified by the task. Unless there are major objections, Adam plans to try to get trapfs merged in the relatively near future. (Log in to post comments)
Trapfs - an automounter on the cheap Posted Nov 4, 2004 20:24 UTC (Thu) by crlf (guest, #25122) [Link] As author of the autofsng patchset, I'd like to point out some of the differences between trapfs and autofsng.
Trapfs was originally developed to deal with trapping access to non-existent device files. The intent to provide devfs style module-loading when a user tries to access non-existent files in /dev. Autofs on the otherhand has a similar albeit very different task: to mount filesystems upon access to non-existing directories as well as to existing directories upon traversal.
The difference in scope is where trapfs provides dynamic manipulation of a given filesystem, autofs provides dynamic manipulation of a system namespace. The two appear to handle the same problem, but in fact the semantic differences distinguish them.
For instance, the semantics for autofs are well defined across various other Unix platforms, and autofsng tries hard to match them. For instance, in autofs you have three kinds of traps:
Contrarily, trapfs (currently) only handles the case of accessing a non-existent fs object (file/directory/device/etc) on a given filesystem.
Another semantic that differs between the two is the expiration of 'trapped' objects. Autofs has defined rules for 'peeling' back automounted filesystems. These rules are complicated due to the combination of hierarchal multimounts and racing with userspace for access. Autofsng solves these problems by making expiry of a complicated hierarchy of filesystems native to the kernel vfs. Similar issues will be seen with trapfs come the time somebody wishes to have directories that are trapped and created recursively.
Given the current state of trapfs, I do not feel it is ready for anything more than a devfs work-a-like [1] or very simple automounting.
Going forward, I hope to work with Adam to see if any of the functionality of the two projects can be merged together.
[1]: preferrably with udev of course :)
|
|||||||||||||