由于业务需求笔者为公司的一台R720服务器加了一块大小约为10T的磁盘(注:该系统承载着公司的部分核心生产数据哦)。理论上应该是没有什么风险和不可控因素存在的,谁知博主也经历了坑爹的小惊险。还好系统最终正常启动起来了,要不博主一世英明神武就毁在一块小小的硬盘手里面了。
具体怎么插入磁盘到服务器、如何使用parted(由于MBR分区表只支持2T磁盘,所以大于2T的磁盘必须使用GPT分区表。但fdisk不支持GPT所以我们使用parted来对GPT磁盘操作)进行分区以及如何使用mkfs命令进行格式化文件系统,博主就不在赘述了。我只说一下最让博主鸡冻不已的地方吧!也算是娱乐大家一下!
博主把磁盘插入到服务器并识别该设备后对其进行了分区、格式化等一系列的操作后。开始手动使用mount命令进行测试该设备是否可以被正常挂载。
步骤如下:
1)创建挂载点
#mkdir /data
2)手动挂载新接入的大磁盘
# mount /dev/sdb1 /data
3)验证该目录是否可以正常使用
#cd /data
#touch fengzhanhai.txt
# df -lh /data
#查看可使用空间大小
#文件系统 容量 已用 可用 已用% 挂载点
#/dev/sdb1 9.8T 0 9.8T 0% /data
Ok!一切都正常 ~
噩梦开始啦!下面博主奔着为了将来便于管理和维护的美好愿望开始了异常让博主激动不已冒险之旅。
4)系统分区的自动挂载
#博主在网络上google,百度了一大通发现自动挂载太简单了。TMD太相信网络了。直接就在生产服务器执行了如下命令:
#vi /etc/fstab
#在该文件的最后添加如下命令,退出后保存。
/dev/sdb1 /data ext3 defaults 1 2
5)重新启动linux进行测试
坑爹啊!linux启动不了。重启N遍后依然panic,随后一身冷汗~
没办法,博主推断肯定是修改fstab的问题导致的系统无法启动啊!于是博主用光盘引导到系统进入rescue模式下,然后chroot之后再次修改fstab文件如下所示:
#vi fstab
#修改模式如下将第五列是否要备份的参数修改成否,将第六列是否使用fsck对该磁盘进行修复性检查设成否,因为1默认是系统根目录,2、3、4等数字磁盘分区(有些同学不知道自己挂载的分号是多少所以建议就不要填啦,否则后果自负哦)。
/dev/sdb1 /data ext3 defaults 0 0
6)退出rescue模式后重启系统
呵呵,终于启动起来了~
通过使用mount命令查看是否/dev/sdb1已经顺利挂载到了/data目录下面了!经过验证ok!