Mounting a File System
When the superuser attempts to mount a file system, the Linux kernel must
first validate the arguments passed in the system call.
Although mount does some basic checking, it does not know which file systems
this kernel has been built to support or that the proposed mount point actually
Consider the following mount command:
$ mount -t iso9660 -o ro /dev/cdrom /mnt/cdrom
This mount command will pass the kernel three pieces of information; the name of
the file system, the physical block device that contains the file system and, thirdly,
where in the existing file system topology the new file system is to be mounted.
The first thing that the Virtual File System must do is to find the file system.
To do this it searches through the list of known file systems by looking at each
file_system_type data structure in the list pointed at by file_systems.
If it finds a matching name it now knows that this file system type is supported
by this kernel and it has the address of the file system specific routine for
reading this file system's superblock.
If it cannot find a matching file system name then all is not lost if the kernel
is built to demand load kernel modules (see the section on modules).
In this case the kernel will request that the kernel daemon loads the appropriate
file system module before continuing as before.
Next if the physical device passed by mount is not already mounted,
it must find the VFS inode of the directory that is to be the new file system's
This VFS inode may be in the inode cache or it might have to be read from the
block device supporting the file system of the mount point.
Once the inode has been found it is checked to see that it is a directory
and that there is not already some other file system mounted there.
The same directory cannot be used as a mount point for more than one file system.
At this point the VFS mount code must allocate a VFS superblock and
pass it the mount information to the superblock read routine for this
All of the system's VFS superblocks are kept in the super_blocks vector
of super_block data structures and one must be allocated for this mount.
The superblock read routine must fill out the VFS superblock fields based on
information that it reads from the physical device.
For the EXT2 file system this mapping or translation of information is quite
easy, it simply reads the EXT2 superblock and fills out the VFS superblock from there.
For other file systems, such as the MS DOS file system, it is not quite such
an easy task.
Whatever the file system, filling out the VFS superblock means that the file system
must read whatever describes it from the block device that supports it.
If the block device cannot be read from or if it does not contain this type of
file system then the mount command will fail.
Figure 9.6: A Mounted File System
Each mounted file system is described by a vfsmount data structure;
see the figure above.
These are queued on a list pointed at by vfsmntlist.
Another pointer, vfsmnttail points at the last entry in the list and
the mru_vfsmnt pointer points at the most recently used file system.
Each vfsmount structure contains the device number of the block device
holding the file system, the directory where this file system is mounted and a
pointer to the VFS superblock allocated when this file system was mounted.
In turn the VFS superblock points at the file_system_type data structure
for this sort of file system and to the root inode for this file system.
This inode is kept resident in the VFS inode cache all of the time that
this file system is loaded.