Bind Mounts and File System Mount Order

     When you use the bind option of the mount command, you must be sure that the file systems are mounted in the correct order. In the following example, the /var/log directory must be mounted before executing the bind mount on the /tmp directory:

# mount --bind /var/log /tmp

The ordering of file system mounts is determined as follows:

1. In general, file system mount order is determined by the order in which the file systems appear in the fstab file. The exceptions to this ordering are file systems mounted with the _netdev flag or file systems that have their own init scripts.

2. A file system with its own init script is mounted later in the initialization process, after the file systems in the fstab file.

   大意是：在初始化过程中，一个带有自身init脚本的文件系统会被挂载，不过，这要在fstab这个文件中所列出的文件系统被挂载之后。也就是说，挂载次序慢于fstab中的文件系统

3. File systems mounted with the _netdev flag are mounted when the network has been enabled on the system.

If your configuration requires that you create a bind mount on which to mount a GFS2 file system, you can order your fstab file as follows:

1. Mount local file systems that are required for the bind mount.

2. Bind mount the directory on which to mount the GFS2 file system.

3. Mount the GFS2 file system.

If your configuration requires that you bind mount a local directory or file system onto a GFS2 file system, listing the file systems in the correct order in the fstab file will not mount the file systems correctly since the GFS2 file system will not be mounted until the GFS2 init script is run. In this case, you should write an init script to execute the bind mount so that the bind mount will not take place until after the GFS2 file system is mounted.

The following script is an example of a custom init script. This script performs a bind mount of two directories onto two directories of a GFS2 file system. In this example, there is an existing GFS2 mount point at /mnt/gfs2a, which is mounted when the GFS2 init script runs, after cluster startup.

In this example script, the values of the chkconfig statement indicate the following:

• 345 indicates the run levels that the script will be started in

• 29 is the start priority, which in this case indicates that the script will run at startup time after the GFS2 init script, which has a start priority of 26

• 73 is the stop priority, which in this case indicates that the script will be stopped during shutdown before the GFS2 script, which has a stop priority of 74

The start and stop values indicate that you can manually perform the indicated action by executing a service start and a service stop command. For example, if the script is named fredwilma, then you can execute service fredwilma start.

This script should be put in the /etc/init.d directory with the same permissions as the other scripts in that directory. You can then execute a chkconfig on command to link the script to the indicated run levels. For example, if the script is named fredwilma, then you can execute chkconfig fredwilma on.

#!/bin/bash
#
# chkconfig: 345 29 73
# description: mount/unmount my custom bind mounts onto a gfs2 subdirectory
#
#
### BEGIN INIT INFO
# Provides:
### END INIT INFO

. /etc/init.d/functions
case "$1" in
  start)
    # In this example, fred and wilma want their home directories
    # bind-mounted over the gfs2 directory /mnt/gfs2a, which has
    # been mounted as /mnt/gfs2a
    mkdir -p /mnt/gfs2a/home/fred &> /dev/null
    mkdir -p /mnt/gfs2a/home/wilma &> /dev/null
    /bin/mount --bind /mnt/gfs2a/home/fred /home/fred
    /bin/mount --bind /mnt/gfs2a/home/wilma /home/wilma
        ;;

  stop)
    /bin/umount /mnt/gfs2a/home/fred
    /bin/umount /mnt/gfs2a/home/wilma
        ;;

  status)
        ;;

  restart)
        $0 stop
        $0 start
        ;;

  reload)
        $0 start
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|reload|status}"
        exit 1
esac

exit 0