RHEL LVM 无损缩根X法Word格式文档下载.docx

RHEL LVM 无损缩根X法Word格式文档下载.docx

《RHEL LVM 无损缩根X法Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《RHEL LVM 无损缩根X法Word格式文档下载.docx（13页珍藏版）》请在冰点文库上搜索。

当然所谓树大招风，LVM的名气不胫而走之后，而且在很多人的眼里，LVM的extend和reduce结合resize2fs的黄金组合似乎独步天下，并在块设备和文件系统的调整中无往不利。

其实LVM的调整方面，被大多数发行版系统官方支持的是lvm的扩展，即extend。

但在尝试了这种功能的平稳性之后，大家似乎开始对LVM的收缩即reduce有更多的兴趣。

因此在各种网站上使用lvreduce来对块设备瘦身的帖子也层出不穷，尽管官方一天到晚扯着嗓子喊这是一种不被支持的操作并且需要自负风险的操作形式。

应该说在咱神州沃土之上其实总不乏一些富有尝试精神的高手，一边冒着在刀尖上跳舞的风险来给我们带来很多来自边缘的惊喜，一边抱着误中自己化骨绵掌的磁盘在寒风中痛哭流涕。

当无数的前人被拍死在沙滩上的同时，更富有精神的后辈不惜将前人的勇敢和变态同时发扬光大。

对LVM的reduce操作不光瞄上了普通的文件系统，而且瞄上了系统的命根子——根分区。

其实本人素来不想搭理这些个人认为无端、无聊和无知的需求：

因为作为稳定要求为至高境界的生产系统和生产环境，本应该在刚刚开始部署的时候有慎重的考虑和规划，一旦部署上线之后就绝不应该或者极少对底层尤其是存储设备大动干戈。

但突然发现最近这方面的需求和探求者越来越多。

所以，一方面，我对大家充分信任并要榨干LVM最后一滴油的想法表示理解；

另外一方面正因为没有做过，所以也隐隐感觉到自己和其他人一样在心底也隐藏着这般的邪念，为此最终决定找台测试环境来实现大家梦寐以求的壮举——对部署了根文件系统的逻辑卷进行缩根操作！

尽管从我个人的理论角度认为，这种操作在经过精确计算是没有问题的，但是有时候人就是比较犯贱，你告诉他不行，非要自己亲手体验一把方能找到快感。

既然如此，所以我就在这里先行爽上一把，然后把我的快感告诉大家！

但是先要郑重声明，本人乃遵纪守法好公民，既然各个发行版将LVM收缩视为洪水猛兽，那么对于各发行版部署文档中提到的LVM收缩的禁区绝对言听计从，之所以在这里操作实在是为了要帮大家出个头而已。

但这个操作有没有风险性，多大风险性，真的在企业中生产环境上操作可能会导致多少人被炒鱿鱼、失心疯、跳楼、卧轨等等的后果本人没有时间也没有鸟兴去考虑，所以各位下手之前最好做足够的测试和论证，如果因为计算失误或者操作失误导致的任何问题，本人只能表示深深默哀，且爱莫能助。

所以各位施主和看官在实施自己的犯罪计划之前望慎之又慎，善哉善哉！

好了，废话不多说，Let’sGo！

按照本人做事的惯例，首先提供一个干活前系统的基本环境：

如图所示：

RHEL5Update2系统，采用默认分区方式，根分区在LVM上，文件系统大小为8G：

然后找张光盘启动系统执行linuxrescue进入到Rescue模式：

有人曾经问我，如何在生产环境下online状态下来缩根，哥们，做人要厚道，事情不要做得太绝！

选择英文语言支持键盘布局，不选择网络，最后的界面是个关键，不要让系统根挂载到/mnt/sysimage上，所以最后的界面这里选择“skip”。

根据我上述的情况，我初步是准备计划将根分区缩小3个G，但是事实上经过操作发现，文件系统在收缩之后，块设备能缩多少这往往不是根据个人意愿而定，而是要根据当前实际文件系统大小来决定块设备也就是LVM的边界。

如果不遵循这种规律，那么你会死得很难看。

那么现在我要做的工作，首先是要探测并激活所有的LVM设备：

我通过lvm.static命令来在当前环境中加载所有LVM的静态库，这样即可在rescue模式下对逻辑卷设备进行操作。

首先的工作自然是要将设备scan出来。

然后再激活卷组：

大凡对LVM进行收缩，必须先收缩其上的文件系统。

实在搞不懂原理的哥们可以这样想，文件系统相当于你的大脑，LVM相当于你的脑壳，如果你的大脑体积比你的脑壳还要大，那么……原谅我，我是个粗人。

言归正传，在进行文件系统调整之前，系统要求对其先执行fsck。

那么如上图照做即可。

完成之后可以将根文件系统按照我们的预期缩小3G：

完成之后强烈建议大家执行fsck，一方面保证该文件系统没有受损，另外一方面也是最关键的是我们要获得这个文件系统目前的size。

根据提示，进行了resize2fsz的文件系统有1310720个块，每个块大小是4k，那么整个文件系统大小即为5120MB（1310720x4/1024）。

这个时候关键的问题来了，文件系统缩了，文件系统所在的逻辑卷到底应该收缩多少？

！

这实际上是整个缩骨X法过程中最富有技术含量的问题了。

前辈们告诉我等要多借助可能的系统工具获得目前LVM的信息，所以开另外一个终端执行lvdisplay以及vgdisplay：

从上面的两个截图显示，我的整个卷组是252个PE，每个PE是32MB，而在同一个卷组中所有PE和LV的大小默认是一致的，而且在同一个卷组中绝对不可能出现两种size的PE或者LE。

这样的话，我们即可以从lvdisplay命令显示的结果计算出目前根分区所在的LVM有多少个4k为单位的block。

方法是236x32x1024/4=1933312，即1933312个4k为单位的块，那么和已经收缩过的文件系统相减即可求出块设备和文件系统大小的差异：

（1933312-1310720）x4/1024=2432MB。

这就意味着，最多这个LVM可以缩2432MB！

富于冒险精神的哥们当然可以缩更多，这是上帝赋予尔等的权力，之后的结果正好也可以让俺这种村里来的也张长见识。

但鄙人胆小，因此只会循规蹈矩按照这个计算结果干活！

如图所示，执行lvreduce之后，按照要求，再去跑一个resize2fs，我们将惊喜地发现，计算结果正好能够吻合文件系统的大小1310720个4k块。

这证明先前的推测和计算已经做到了分毫不差！

呵呵呵！

在继续之前先得意一把！

不过最后，保险起见，跑一次fsck确保根文件系统没有问题并挂载测试还是必要滴。

结果如图所示，发现一样能成功，根文件系统所在的LV实际上收缩了2个多G。

估计再多的话，根分区在fsck的时候即会有一堆的error。

那么现在我们即可重启机器，欣赏经过自己一番压榨之后的系统：

貌似一切正常，进入系统检查，真的一切正常吔！

无疑操作是成功了！

从上面的操作来看，本来文件系统有8G，我在将其缩小到5G的时候，其所在的LV只能缩小2个多G才能保证文件系统安全。

这也很容易解释，因为Ext3文件系统的布局处于优化性能的考虑是按照块组划分，每个块组中的块数量和结构基本上是一致的，那么前前后后可能会有一些不是我们通过常规计算所能获得的数值，所以实际上我们看到的df之后的结果，并不会是这个文件系统完全在物理上的size。

不管怎么说，这次缩骨X法是成功了。

有些人可能会问，如果我的根分区不在LVM上，而是在sdx上的某个分区，那么应该怎么整？

其实我可以负责任地告诉各位，操作的思想一样，而且因为没有了LVM在rescue环境中加载的问题，步骤相对其实会更加简单。

有兴趣的哥们可以在自己的环境中测试一下，总不能什么玩意都指望在下。

不过当然我从来说话给自己留后路，如果哪个虔诚的哥们愿意找我喝个茶，吃个包，沟通一下感情的同时探讨一下LVM什么的那就另说，如果是MM或者PPMM那就更另说。

但最后还是不忘唐僧一下：

*系统部署之前考虑清楚自己今后的需求，不要顾前不顾后，顾头不顾尾。

*没有迫不得已的需求，不要考虑缩根；

如果要考虑缩根，不要考虑在线缩根；

如果要在线缩根，不要……算了，当我没说！

*缩根的时候没敲一个回车之前都必须经过慎重和精确的计算，缓冲度尽量放大些，反正以后还可以执行resize2fs，数学不好的哥们要慎重……

*最后，如果因为各种各样的原因缩出了问题，那么我这唐僧就算成了佛也没法帮你，因此有条件务必做好备份先。

善哉善哉！