今天有两台Amazon 的云服务器需要扩容磁盘(EBS)空间，在大概两个月之前我曾经为一台云服务器进行过类似操作，当时可是第一次操作，战战兢兢每步都万分小心地完成了工作。
(图源 ：pixabay)
当时还把操作步骤写了一个帖子《Amazon EC2动态扩展挂载磁盘(Volume)空间》，且煞有介事地总结了三大步骤：
- 面板中调整对应Volume的空间大小
- 系统中拓展分区大小(growpart)
- 系统中调整文件系统(resize2fs)
这次也算是有经验啦，直接撸起袖子就是干，先在面板中调整以下空间大小，而且一边调整大小，一边给云服务做了一下升级，这边面板中调整完了，那么升级了进行到了尾声。
按着我以前的操作经验，我应该先完成扩容相关的调整，然后再一并重启云服务器。可是这次突然手残给重启了，重启就重启吧，也没啥大不了得的，重启完再调整吧。
可是重启完，我试着看了一下空间占用情况：
df -lh
什么？空间已经是调整完的空间大小啦？可是我一堆操作还没执行呢？比如growpart，又比如resize2fs！这好比我憋了一堆大招没有发出去，敌人就死了，这让人情何以堪？！
再回想起我之前的帖子里记录的一堆大招，突然觉得有点脸红。不过不对呀，明明Amazon操作界面上也是提示要拓展文件系统呢？
莫非是我已经执行了我的大招，而我忘记了？不过没关系，不是还有一台云服务器要处理吗，用这个操作并验证一下，就知道是不是我放完大招忘记了。
而事实给了我当头一棒，果然在界面里扩容并重启云服务后，一起都正常，根本不需要什么growpart，又比如resize2fs，大招变成了昏招。
不过又仔细想想，好像大招还是有用的，因为这次操作，我动用了重启大法，如果有应用不能中断，并且空间还不够用了，那么在线不停机扩容就是非常有必要的了，而大招可以做到这点。
所以大招还是大招，只是在这种不需要不停机的情况下，有那么一丢丢昏招的意味。
(图源 ：pixabay)
另外，顺便说一句，重启大法真是好啊，相比瞪大双眼和一堆命令和字符打交道，重启大法简单粗暴高效率，简直就是事半功倍呢！
相关链接
This page is synchronized from the post: ‘昏招与大招：动态扩容EBS空间’