有一台业务服务器安装的是suselinux系统,，上面挂载的远端存储卷在系统重启之后就挂载不上，导致系统都启动不了，因为系统会一直去扫描存储卷，直到等待一定时间之后提示你进入救援模式。
1、查看系统信息
linux-92bv:~ # lsb_release -a
LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
Distributor ID: SUSE LINUX
Description: SUSE Linux Enterprise Server 11 (x86_64)
Release: 11
Codename: n/a
linux-92bv:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
2、查看分区表挂载的存储卷信息
linux-92bv:~ # more /etc/fstab
。。。此处省略其他分区信息
#/dev/tmsvg/oradata /ora_data ext3 acl,user_xattr 1 2
这里可以看到，业务管理员为了快速恢复应用，已经修改服务器分区表，然后重启服务器，手动挂载该设备，恢复应用了。问题嘛，慢慢查。
3、我的解决办法
1）发现fstab文件内的最后两个选项有问题，于是修改为准确值。 具体修改的地方大家对照着看吧，两行信息的最后两列做了修改。defaults是按照系统默认最简单方式做挂载，0 0这个参数，注意中间有空格，定义的文件系统是否需要dump备份和是否需要做fsck校验检查。最简单配置的就是0 0，设置为1 2，会有其他问题。推荐的配置是，跟分区对应的设置为1 1，其他分区均为0 0。
linux-92bv:~ # more /etc/fstab
/dev/tmsvg/oradata /ora_data ext3 defaults 0 0
#/dev/tmsvg/oradata /ora_data ext3 acl,user_xattr 1 2
2）这个脚本主要是为了在读取分区表文件fstab之前，先手工对存储卷做识别处理。之前无法挂载的根本原因是在系统读取分区表之前该设备还未来得及挂载，肯定会出问题的嘛。
linux-92bv: # more /etc/init.d/after.local
mount /dev/tmsvg/oradata /ora_data
总结：
1、fstab先被执行，然后才会执行/etc/init.d目录下的内容
2、遇到因为fstab配置存储卷自动挂载信息导致系统无法启动的情况，fstab干脆就不要写存储卷的挂载信息了，直接到开机启动项目录下配置更好。之前不能正常挂载存储卷的原因应该是，系统启动的过程中，需要启动和加载的设备、驱动程序等非常多，有可能因为驱动问题或者机器性能不好导致的启动队列延迟、或者系统内部启动队列机制出现异常等，造成系统挂载fstab文件内的分区之前，光纤卡驱动或者相关设备却还未准备好，最后的表现就是系统的fstab正确，但是不能自动挂载存储卷，必须通过手动方式挂载。
弄清楚了原因就好办，我们直接在开机启动项目录，也就是/etc/init.d/内加一个文件叫after.local，写入你要加载的分区信息即可（其实就是你手工方式mount分区的语句，拷贝过来即可）。至于这个after.local，不能随便命名为别的名称的，这个是操作系统开发包内已经定义好的文件名。
___________________________________________________________________________________
版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!
Author: laven54 (lurou)
Email: laven54@163.com