linux增加/根目录的磁盘空间（基于LVM)

linux增加/根目录的磁盘空间（基于LVM）
问题引出：

在测试过程中替换so文件，报磁盘空间不足的错误

[root@UF2 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 28G 27G 0 100% / /dev/sda1 99M 9.1M 85M 10% /boot none 1014M 5.4M 1009M 1% /dev/shm /dev/sdb1 19G 77M 18G 1% /NewDisk [root@UF2 ~]#

问题分析：

这是一套公司的系统，由于当时系统部署架构的考虑，把中间件和数据库部署在同一台机器上了，并且给了30G的磁盘空间。

系统上占用磁盘空间的有2部分，一是软件本身（我们的中间件），二是安装的oracle数据库。使用du命令，大概查看了下所写磁盘大小，发现都是在长期操作中，写到后台数据库的数据越来越大，导致数据库的表空间越来越大，对应的物理文件就是datafile，占用了很大的表空间。

问题解决方法分析：

1、 系统不做改变，对数据库的一些log、不用的数据进行删除

2、 注意到系统还有一块20G的空磁盘没有使用(/dev/sdb1)，把数据库生成的数据迁移一部分到这块新的磁盘并指定新生成数据到这块磁盘上

3、 注意到系统的磁盘部署，当时使用的是lvm逻辑卷进行管理的，LVM的一个优点就是方便进行逻辑卷的动态增加，可以把/dev/sdb1这块物理磁盘加到根目录所在的卷组里面，然后对根目录所在的逻辑卷进行扩容

最后决定：方法1,2都是可行的，对自己的oracle稍有把握的人都可以实现。本人决定采用方法3，一是考虑系统本身会不断的产生日志等增加空间，这样整个磁盘都被系统所用，当然包括我们的中间件和数据库；二是当时设计这个系统构架的采用LVM进行管理的，可能也想到了后面虽然业务的增加，磁盘空间将不够，将要进行动态扩容。这种设计的理念的是OK的，但是这种设计也有他很大的局限性，下面再进行分析

LVM逻辑卷扩容的3种模式介绍

以下是自己对LVM逻辑卷进行扩容的实际应用中的3种模式进行了归纳和总结（个人观点）

1、 不涉及根目录的磁盘(自己用画图附件画的图，有点龊哈)



如上图所示：sdb1只是普通的数据卷组了逻辑卷，没有被linux的根目录所用，这个时候，可以把第一块磁盘剩下的未使用的分区（sdb2）以及第二块磁盘sdc，第三块磁盘sdd等都可以通过LVM管理加进逻辑卷组，然后对逻辑卷进行扩容

2、 涉及根目录的磁盘1



如图所示：sda1被根目录使用，组了逻辑卷，sda2是平常所说的linux的swap分区，和根目录在同一个卷组下，只是属于不同的逻辑卷，这个时候，如果根目录磁盘空间不够了，要对其进行扩容。如果这块sda当时设计的时候还有很大一部分空余磁盘空间未用，那么很庆幸的告诉你，这样也是很容易把剩余的磁盘空间通过LVM加到逻辑卷组，然后对逻辑卷进行扩容的。

3、 涉及根目录的磁盘2



如图所示：sda1被根目录使用，组了逻辑卷1，sda2是swap分区，第一块磁盘sda空间已经用完，必须通过新加的磁盘sdb，对根目录所在的逻辑卷1进行扩容。那么，恭喜你，中奖了，这是最麻烦的一种情况。要对逻辑卷进行动态调整，调整的时候要重新挂载文件系统。因此根目录的调整与其它lvm管理的文件系统的调整稍有不同，必须先进入rescue模式。如果没有linux系统相关经验，很可能就死在最后一步linux
rescue上。

具体解决问题步骤

1、 对系统做快照

这是我们测试组的真实测试环境，以下所做的操作涉及到根目录逻辑卷的调整，万一把系统给弄挂了，那肯定是要挨批的。

事实上，自己在解决这个问题之前，也只是理论分析，以为和LVM逻辑卷扩容的3种模式介绍中的1,2方式一样容易解决，把系统搞死了很多次，也幸亏做了虚拟机快照，才能保证万一解决不成功可以回退或者多次实验的可能性。网上查找资料的时候，也遇到一些同行做这个操作的时候，把系统搞死了，不知道去linux rescue的时候，最后把系统重装的恶果。

2、使用LVM进行逻辑卷的扩容

（1）对系统新加磁盘并使用fdisk进行分区（这里已有省略）

（2）查看系统的逻辑卷组vg和逻辑卷lv

[root@UF2 ~]# vgs VG #PV #LV #SN Attr VSize VFree VolGroup00 1 2 0 wz--n 29.88G 32.00M [root@UF2 ~]# lvs LV VG Attr LSize Origin Snap% Move Copy% LogVol00 VolGroup00 -wi-ao 27.91G LogVol01 VolGroup00 -wi-ao 1.94G

或者使用vgdisplay和lvdisplay

[root@UF2 ~]# vgdisplay --- Volume group --- VG Name VolGroup00 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size 29.88 GB PE Size 32.00 MB Total PE 956 Alloc PE / Size 955 / 29.84 GB Free PE / Size 1 / 32.00 MB VG UUID Fj19eG-A1Ev-qs48-yI6b-HoL6-INnf-GwThFD [root@UF2 ~]# lvdisplay --- Logical volume --- LV Name /dev/VolGroup00/LogVol00 VG Name VolGroup00 LV UUID SRV5oM-Kndv-QlHn-68Pq-OlvT-LdJj-julBsj LV Write Access read/write LV Status available # open 1 LV Size 27.91 GB Current LE 893 Segments 1 Allocation inherit Read ahead sectors 0 Block device 253:0 --- Logical volume --- LV Name /dev/VolGroup00/LogVol01 VG Name VolGroup00 LV UUID RxmWcw-lV95-O4T4-HanR-RvqZ-UEPZ-NPLh04 LV Write Access read/write LV Status available # open 1 LV Size 1.94 GB Current LE 62 Segments 1 Allocation inherit Read ahead sectors 0 Block device 253:1 [root@UF2 ~]#

(3)对新磁盘创建pv

[root@UF2 ~]# pvcreate /dev/sdb1 Physical volume "/dev/sdb1" successfully created

(4)把PV加入VG

[root@UF2 ~]# vgextend VolGroup00 /dev/sdb1 Volume group "VolGroup00" successfully extended

并使用lvdisplay 和 vgdisplay进行检查确认

（5）扩展lv

[root@UF2 ~]# vgs VG #PV #LV #SN Attr VSize VFree VolGroup00 2 2 0 wz--n 48.50G 18.66G [root@UF2 ~]# lvextend -L +18.5G /dev/VolGroup00/LogVol00 /dev/sdb1 Extending logical volume LogVol00 to 46.41 GB device-mapper ioctl cmd 9 failed: Invalid argument Couldn't load device 'VolGroup00-LogVol00'. Problem reactivating LogVol00

由于我们的系统环境是LVM逻辑卷扩容的3种模式介绍中介绍的第三种情况，所以此时，系统就hang住了。

当时以为是在ssh远程操作的结果，后来在图形化界面的终端进行操作还是同样问题。后来经过查找资料，才知识是因为调整的时候要重新挂载文件系统。因此根目录的调整与其它lvm管理的文件系统的调整稍有不同，必须先进入rescue模式。进入rescue模式，需要挂载iso光盘，弄到晚上9点多了，手头上没有iso光盘，就回去睡觉下载了一个，然后第二天用移动硬盘拷过来继续干

2、 linux的rescue模式

重启系统，系统就这幅德行了



当然很着急，还好后面进行了问题的解决

挂载iso镜像，并设置系统从CD ROM启动



在boot：里面输入 linux rescue进入linux系统救援模式

按照提示一步一步进行，在是否启用网络的时候选择不启用



进入下一步之后



选择continue之后，按照提示进行命令界面

df是查看分区挂载情况

由于要重置逻辑卷的大小，所以要把挂载的文件系统给卸载了，使用umount

然后是vg的激活，vgchange

和最后的调整文件系统大小，使用lvm vgchange 和 e2fsck，具体看截图





这个时候，再shutdown -r系统，就OK了，但是启动系统之后出现以下问题：



是因为linux系统启动的时候读的/etc/fstab的配置文件内容没有变，但是我们调整了磁盘的部署，解决方法如下：

在以上界面输入root用户的密码，进行维护：



发现没有挂载/boot分区,使用vim /etc/fstab查看配置文件内容



把 LABEL=/boot的分区类型由ext4修改为ext3，并把/dev/sdb1这段注释掉，如下



保存退出，重启，之后就OK了

调整之后的分区情况如下：