User: Password:
|
|
Subscribe / Log in / New account

Trapfs - an automounter on the cheap

Trapfs - an automounter on the cheap

Posted Nov 4, 2004 20:24 UTC (Thu) by crlf (subscriber, #25122)
Parent article: Trapfs - an automounter on the cheap

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:
- when accessing a yet-non-existing-directory
- when accessing a 'ghosted' directory (the autofs 'browse' option)
- when accessing a directory on another filesystem (to perform lazy-mounting of a hierarchal multimount entry).

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 :)


(Log in to post comments)


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds