Hacking the Linux Automounter—Current Limitations and Future Directions Ian Maxwell Kent Jeff Moyer Red Hat, Inc. Red Hat, Inc. [email protected] [email protected] Abstract nel interface. The second major problem sur- rounds the use of multi-mount entries for the /net, or -hosts mount maps. Because of The IT industry is experiencing a consider- the nature of multi-mount maps, the Linux im- able shift from proprietary operating systems plementation mounts and umounts these direc- to Linux. As a result, the features and func- tory hierarchies as a single unit. This means tionality that people have come to expect of that clients mounting exported filesystems from these systems now must be provided for on large servers can experience resource starva- Linux. An automounter provides a mechanism tion, causing failed mounts. The root problem for automatically mounting file systems upon is described and we show how the kernel and access, and umounting them when they are no Linux automounter can be modified to address longer referenced. The Linux automounter is this issue also. We conclude with a review of not feature-complete and there are cases where the progress of the work outlined above and Linux autofs is just plain incompatible with im- give a summary of future directions. plementations from other proprietary vendors. In order to solve the current automounter lim- itations, we start by developing an understand- ing of how things work today. We explain 1 Introduction the basic configuration of autofs for a client machine using simple examples. Then walk With even a modest amount of information, through the the internals for basic operations, network clients often need many mount entries such as the mounting, or lookup, of a direc- in their tables to make the organization’s infor- tory and the umounting, or expiry, of a direc- mation available. To make matters worse, the tory. This includes a description of where aut- mount tables often change. The administrative ofs fits into the VFS layer. Next we discuss overhead is not workable. This leads to heavy the two main deployment difficulties. The first use of an automounter in many enterprises. is that the Linux automounter implements di- rect mount maps in a way that is incompat- An automounter provides the ability to manage ible with that of every other implementation. mount tables centrally, automatically mounting We discuss the desired behavior and compare entries on demand and umounting them after it with that of the Linux automounter. We will a predefined period of inactivity. In addition to then discuss the current development effort to the reduction in administrative overhead, an au- overcome this by extending autofs and its ker- tomounter provides a dramatic reduction in the 38 • Hacking the Linux Automounter—Current Limitations and Future Directions resources needed to have a significant number 2 Unix automounter of file systems available on demand from an ar- bitrary number of network servers. Every commercial Unix platform has an auto- Many enterprises are adopting Linux as client mounter implementation with a standard set of features. The most well known implementa- workstations and server platforms, which has TM TM considerably increased the use of the Linux au- tion is the one found in Sun Solaris . It has tomounter in the past two years. As a result, set the standard for what to expect in an auto- bugs are identified and deficiencies are pointed mounter. out. Most importantly, places where the Linux implementation differs from that of industry 2.1 The master map standard implementations have become a sig- nificant issue. The most commonly raised dis- crepancies are: An automount configuration consists of a mas- ter map describing the mount tables it man- ages. It is generally located in the /etc di- • The Linux automounter implements direct rectory and is called either auto.master or maps quite differently from the industry auto_master. It consists of a line for each standard. automount managed mount point, formatted as follows: • Multi-mount maps are mounted and umounted as a single unit. mount-point map-name [mount-options] • Browsable maps are not the default. mount-point • The Linux automounter does not support mount-point is the full path of the direc- included maps tory of the mount point. If the directory • The Linux automounter does not support does not exist, it is created. The excep- the -null map. tion to this convention is that the entry may begin with a plus (+) followed by a map- • The Linux automounter does not consult name, which causes the specified map to /etc/nsswitch.conf as it should for be included from its source as if it were determining the source of an automount itself present in the master map. map. map-name map-name is the name of the map con- Each of these issues causes problems in mixed taining the mount table. If it begins with environments, where Linux automount clients a slash (/), it is interpreted as a local file share the same maps with other vendor imple- name. Otherwise, the name service switch mentations, typically provided by a NIS server. configuration is used to locate the source They also cause problems in migrations to of the map. This can also be one of the Linux from proprietary Unix platforms, where special maps: -hosts used to mount ex- maps must be changed to either do things the ports from hosts on the network, or -null Linux way, or work around the limitations of used to mark a mount-point to be ex- the Linux automounter. We will discuss these cluded when parsing subsequent master issues and others in Section 4. map entries. 2006 Linux Symposium, Volume Two • 39 mount-options offsets that each must start with a slash (/). mount-options is an optional comma sepa- If the first offset is /, then it is optional. rated list of mount options to be applied to These offset mount entries are referred to the entries in the map unless entries in the as multi-mount entries in Linux autofs. map specify their own options. There are a number of standard macro substi- Lines beginning with a # are comments and are tutions available for use in location specifica- ignored. Long lines may be broken by quoting tions. They are commonly used in multiple ar- the new line character with a backslash, as is chitecture environments. A description of those common practice in configuration files. normally available can be found in [2] on page The special mount point /- is reserved to indi- 190. For those understood by Linux autofs, see cate that the map is a direct mount map and is autofs(5). not associated with any specific top-level direc- As in the master map, lines beginning with a # tory. are comments and are ignored, and long lines may be broken by quoting the new line charac- 2.2 Mount maps ter with a backslash. A map key of * denotes a wild-card entry. This Mount maps consist of two types—indirect and entry is consulted if the specified key does not direct—and have the following basic format: exist in the map. A typical wild-card entry looks like this: key [mount-options] location * server:/export/home/& key key is the name used to look up mount ta- ble entries in the map. For indirect mount The special character & will be replaced by the entries, this is the name of the directory provided key. So, in the example above, a upon which the mount will be made. For lookup for the key foo would yield a mount of direct mount entries, this is the full path server:/export/home/foo. leading to the directory upon which the mount will be made. The timeout on mounts points defaults to ten minutes and can be changed using a command mount-options line option when the service is started. mount-options is an optional comma- separated list of mount options to be ap- plied to the map entry. 3 Linux automounter—autofs location location specifies the file system that is to be mounted on key. It can be a single file The Linux automounter differs in relatively few system or a number of file systems to se- ways from traditional Unix automounter imple- lect from using availability and proxim- mentations. In fact, all of the information pro- ity metrics. It may also consist of multi- vided in the last sections regarding configura- ple key [mount-options] location tion data apply to the Linux automounter as 40 • Hacking the Linux Automounter—Current Limitations and Future Directions well. This section begins with a description of broken up into the daemon proper and a set of the Linux-specific details of the master map, loadable modules. To understand how the dae- and then moves on to the architecture of the mon operates, we will walk through the dae- Linux automounter. mon startup for a minimal setup. Consider the following auto.master map: 3.1 Linux autofs master map /net /etc/auto.net The Linux autofs master map syntax is a super set of the standard automount master map syn- tax. This is partly because Linux autofs does We will not show the contents of the program not utilize the name service switch to locate the map, auto.net, as it is shipped with aut- source of maps and so must allow it to be spec- ofs. Autofs startup begins with the init script. ified. This script parses the auto.master map and spawns one automount daemon for each mount The syntax is: point listed. The example given above will re- sult in an automount command with the follow- ing parameters: mount-point \ [maptype:]map-name \ /usr/sbin/automount \ [mount-options] /net program /etc/auto.net The fields above are the same as those de- As shown above, the daemon takes as its op- scribed in Section 2.1 (“The master map”), ex- tions a mount point, the type of the map to be cept for the maptype, which can be one of loaded, and the name of the map to be loaded.