非LVM环境中根分区的调整

蓦然高贵

    大概是因为Linux系统相比于微软等系统具有超强的灵活性和透明度的关系，长久以来从来不乏
富于想象力的兄弟姐妹总是不断摩拳擦掌地准备将这种在灵活和透明上建立起来的可调控性发挥到
极致。

    正因为这样，经过不懈的铤而走险才有像LVM缩根、单盘分身Raid 1等极度刺激和过瘾的方
案不断从本人手中孕育出来。当然测试和总结这些方案的初衷基本上都是来自于很多企业和生产环
境中的客户顾头不顾腚的前期部署。我们完全有理由相信，并且也时刻做好准备，在今后肯定会有
更多神来的想法让我等游走于这种生死之间。所以今天的非LVM环境的分区调整又让我体验了一把
刺激。废话不多说了，具体情况大概是这样：

　  在某生产环境中有一台Red Hat Enterprise Linux 4的服务器，只安装了一块160GB的磁盘，
所有的文件系统都部署在非LVM的普通分区环境中。但在当年部署该系统的时候估计那哥们的脑袋
让驴踢得不轻，整了一个/boot 分区100MB，/分区为120GB，数据分区为40GB的结构。结果显
而易见，该服务器没跑多长时间，存储数据的文件系统即开始告急，但客户又不想将数据放在根分
区下，估计用过Windows上类似分区魔术师之类的软件，所以自然就又打起了调整根文件系统的主
意。要实现的目的如图：

调整前：
|/boot 100MB|----------------/ 120GB-----------------| -------/data 40GB-------|
调整后：
|/boot 100MB|--------/ 40GB--------|------------------- /data 120GB ------------|
这个对比图相信大家都看得明白，无损数据是基本要求。

   　这的确是个很有意思和很刺激的需求。其实要说做到也并不能难。尽管没有LVM的环境，这种
做法不单适用于分区的缩小，而且也可适用于非LVM环境中的分区的扩大，而且事实上缩小的操作
要比扩大的操作难度更大。但事实上个人认为关键的问题不在于扩大和缩小，而就在于一个字——
“算”。我没有办法找到和用户一样的环境，除非有人愿意给我捐一块盘，所以只有找一个虚拟机
来模拟测试环境。
这是一个用虚拟机构建一个RHEL4.7的系统，安装在一个4GB的磁盘上，该系统的分区结构如下：

    [root@localhost ~]# fdisk -l
Disk /dev/sda: 4294 MB, 4294967296 bytes
255 heads, 63 sectors/track, 522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
    /dev/sda1 * 1 13 104391 83 Linux
    /dev/sda2 14 274 2096482+ 83 Linux
    /dev/sda3 275 522 1992060 83 Linux


而df文件系统：
[root@localhost ~]# df -TH
Filesystem Type Size Used Avail Use% Mounted on
   /dev/sda2 ext3 2.2G 802M 1.3G 40% /
   /dev/sda1 ext3 104M 13M 86M 13% /boot
   none tmpfs 131M 0 131M 0% /dev/shm
   /dev/sda3 ext3 2.1G 44M 1.9G 3% /data1
[root@localhost ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
   /dev/sda2 2063536 782996 1175716 40% /
   /dev/sda1 101086 12222 83645 13% /boot
   none 127332 0 127332 0% /dev/shm
   /dev/sda3 1960716 42220 1818896 3% /data1

　　我的目标是最大化地将根分区缩小。根据这里显示文件系统和块设备的大小，我的目标是将原
本存在于/dev/sda2这个2GB磁盘分区上的根文件系统和/dev/sda2分区本身缩小至少1GB，因
为系统当初是采用RHEL4的最小化安装，所以应该只有800GB左右；而同时将压缩出来的空间提供
给/dev/sda3。
　　现在开始进行操作。由于要对根进行操作，所以无论如何也得进入rescue先。操作之前先计算
一下，如果根缩小1GB的话，剩下的空间是否满足文件系统的要求：
1GB = 1024 x 1024KB = 1048576KB；
2063536KB – 1048576KB = 1014960KB；

　　这证明即便缩小根文件系统1GB，也能为当前的系统根提供足够空间（782996KB）。所以就以
此为目标开干！先进入到rescue模式下，在提示是否挂载系统根的时候选择“skip”，以备后续手
动挂载文件系统。创建目录/mnt/sysimage备用。现在开始对根分区进行调整。
首先检查该文件系统：# e2fsck –f /dev/sda2
调整journal：# tune2fs -0 has_journal /dev/sda2
然后缩小该文件系统到所需大小：# resize2fs /dev/sda2 1014960k

file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-0.png
在这个操作成功之后，需要挂载/dev/sda2和原来的/dev/sda3以测试文件系统通过刚才的折腾是否OK。

file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-0.png

同时查看fdisk –l的信息，准备将根分区所在的块设备sda缩小到合适大小。
　
  　这个地方是最考人的，由于fdisk严格来说是以柱面大小为单位计算容量的，所以我们要将已经缩小之后的文件系统换算成柱面数量，再决定当前/dev/sda2这个文件系统到底需要多少柱面。

比如这里根据图示缩小之后的文件系统只有998472KB，按照df命令1KB为单位计算的。

而通过fdsik–l显示的结果，每个柱面为8225280字节，所以现在开始换算：
998472 x 1024 / 8225280 = 124.30401 柱面

　　也就是说，精确角度来说需要为/dev/sda2分配124.30401个柱面，而这里为了保证分配的柱面数足够而应该分配整数的柱面数，即125个；而且同时不要忘了。

从fdisk –l的结果看来，sda2原本从14柱面开始，但并不意味着其起始位置就可丁可卯地在第14柱面开头，因为一个柱面有接近8MB，换句话说，如果该分区开始的位置在14柱面的靠后部分则还需要分配额外的空间。

考虑到这种情况可能出现，所以需要再增加一个柱面，即126个柱面。即新的/dev/sda2起始和终止位置应该是14柱面到140柱面。
　　因此在大致的考虑和计算之后可以进行分区的调整。方法是运行fdisk /dev/sda，
将/dev/sda2删除，但注意千万不要保存分区表，然后接着直接建立新的/dev/sda2分区。将起始和终止柱面设置为14和140柱面，然后保存分区表。

   
file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-0.png

然后再次挂载文件系统并运行resize2fs自动调整文件系统到合适大小。
　　这个操作完成之后，首先可以确认的一点是分区和文件系统都调整成功了！而且从刚才最后一次df命令显示微调结果看来，文件系统扩大了5MB左右。证明刚才增加的126柱面的算法还是正确的。
　　现在另外一个关键的问题就是如何压缩出来的磁盘空间来扩展sda3。事实上如果可用空间
在/dev/sda3文件系统的后面，那么resize2fs是可以的，因为这种情况下原来文件系统的
superblock位置是不变的。

但是现在这个情况正好相反，可用空间在/dev/sda3的前面部分，所以如果按照刚才的方法来强行扩大分区将造成文件系统无法被读取。

file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-0.png

　　对于这个问题我们目前没有更好的方法，只有将原来的/dev/sda3文件系统先备份出来，然后在这个环境中将/dev/sda2删除。

再通过fdisk重新建立并mkfs创建文件系统。为了测试需要，我随便拷贝一点数据上去，然后备份该文件系统的内容到/mnt/sysimage目录下。

file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-0.png

　这种方法可完成整个文件系统层面的备份，而且备份的数据和实际数据大小一致。当然也可以用tar等工具，反正只要完成备份即可。

最后删除原来的/dev/sda3利用现在的起始柱面和默认的终止柱面重建sda3，并格式化。然后将备份集还原，到此一切操作即成功！

file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-0.png

最后重启整个系统进入正常模式，一切正常，调整顺利完成！
　　纵观整个测试过程，美中不足的是在这种情况下没法对/dev/sda3进行调整，当然可用空间再/dev/sda3文件系统的后面部分又是另外一回事。
　　其实这种情况也可以使用一些第三方工具如qtparted等试试。应该也可以有不错的效果。在这个试验中，主要是我们设计的环境比较险恶。不过这完全可以回应一些对调整非LVM上ext文件系统和块设备大小有需求的哥们。
　　不过不管怎么说，在LVM上操作时标准和科学的做法，毕竟在那个环境中软件在帮你进行最关键的计算；而这种冒险的方法，除非你能很好把握，否则最好不要轻易尝试。


开源时代 2009年9 月刊 - 59
              ChinaUnix.net -----全球最大的Linux/Unix应用与开发者中文社区


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/103725/showart_2053398.html