AutoFS - Automounting Filesystem for FreeBSD 6.x

AutoFS on FreeBSD 6:

The file system is one of the most fundamental constructs of modern computer usage to almost any class of user. Anyone from the casual Web surfer to the dedicated developer relies upon this simple, subtle, yet crucial technology to save, file, and later review his work. One's installed software is saved in various files in the file system, as are one's own valuable work. Because this technology is so ubiquitous and relied upon, improvements in performance or capability to this simple mechanism will reap great rewards for system vendors, and users alike. System vendors can market their product's improvements over the status quo as value added, and improve their competitive edge in the software systems market. Users benefit, because all great software products will have these improvements to remain competitive. However, economics aside, improvements to the file system and it's access methods are arguably the easiest way to improve any software system.

Filesystems store, organize, and retrieve data for users and often these files are stored on remote machines, or removable media. The UNIX system requires that these filesystems must be mounted before files can be accessed. In network environments, mounted filesystems can result in extra traffic, even when the filesystem is mounted, but no files are used. This extra traffic is undesirable, and adversely affects the available network bandwidth, and mounted filesystems require more in-kernel memory and datastructures to maintain them as "active." Nobody wants to keep remote filesystems mounted, when they're not in use. AutoFS works with AMD, a daemon which auto-mounts filesystems, to provide an on-demand mounting facility. The purpose of AutoFS is to limit the load upon AMD, and to provide a layer of kernel control over mounting. This control is used to minimise the number of calls to the Automounting daemon (AMD) thereby providing better performance as a user navigates the "unified" filesystem tree.

Removable media can also be serviced by the automounter. Users often expect their removable media to be available on-demand, without requiring a user-issued command to attach the filesystem to the unified tree. AutoFS can be used to intercept calls, for AMD, and determine whether AMD must mount a filesystem. AutoFS maintains an in-kernel state, to ease the burden upon AMD, and to provide for the ability to service directory lookups which do not need AMD to mount filesystems. AutoFS can be used to ease the user-burden for removable media -- user access patterns for removable media revolves around using a set of files from a removable media filesystem, then removing the media, and perhaps inserting another removable volume, to access another set of files. For example, the user will insert a CDROM, access a set of documents and images, then remove the disc, and insert another, and copy a set of binaries and music to another directory.

AutoFS must be written to have an internal timer, removing stale filesystems from the "mounted" status, should the filesystem be inactive. The current AutoFS protocol is also very obsolete, and has many shortcomings. I have been writing an AutoFS implementation for FreeBSD, implementing a new protocol which will be a model for other future implementations on other operating systems. This AutoFS will have a restartable, transaction based protocol. AMD, should it crash, must be able to interact with AutoFS and find out the current system state for the set of paths it monitors. This AutoFS will allow "in-place" mounting wherein the filesystem can be mounted directly over a path that AutoFS monitors, without forcing AutoFS to stop the AMD process. The AMD mounter and AutoFS will communicate using an "asynchronous" protocol, whereby AutoFS can request several mounts of AMD simultaneously, and AMD will report successes in any particular order. This will allow AMD to be rewritten or modified in a multithreaded fashion, and allow for more responsive filesystem activity on operations which will work with several paths at once. AutoFS will also track an internal listing of mountable and nonmountable paths, which nonmountable paths AMD should never receive notification about access, but mountable paths AMD must be notified if the path in question is not mounted.

Hopefully this will allow FreeBSD to move to the forefront of the field regarding automount features, and make the system a reference platform for the creation of future AutoFS implementations on other systems. In other words, developers will look to FreeBSD as an example for implementation of this feature, opposed to the normal situation, where FreeBSD must strive to work like other systems. It is also possible that AutoFS could be easily ported to other UNIX systems in the BSD family, with great ease.