1、问题背景
在备份——>扩容——>恢复场景中，恢复时修复ext4文件系统容量的大小，resize2fs命令失效。(单纯的扩容，执行resize2fs有效)
注意: 这里的resize2fs代表了一系列动作，包括对分区修复(parted先修复，然后再删除第三个分区，以新的盘最大位置再重建第三个分区)以及ext4的容量扩大(使用resize2fs命令)。
2、问题现象
不论是扩容还是使用扩散前的备份进行恢复，都需要对分区修复(parted先修复，然后再删除第三个分区，再重建第三个分区)以及ext4的容量扩大(使用resize2fs命令)。
为什么后者也要修复呢？
因为IAAS层的块存储的硬盘只能扩容，不能缩容，也就是说一旦硬盘容量扩大了，就不能缩小了。
而扩容流程的修复分区和resize2fs没问题，即ext4按照预期的结果扩大了，恢复流程的resize2fs也照样能够执行成功，但实际上是失效的，即虽然resize2fs执行成功了，但是ext4的容量却未如期扩大。
3、原因分析
一个基本知识: ext4使用了journal机制，而resize2fs命令的执行有个前提，就是journal里面的数据必须刷干净，即外层流程必须clean umount(这里读了e2fsck的源码，很有意思)，如果journal未刷干净，resize2fs命令不感知journal，仍然会执行成功，但是ext4容量却不能如期扩大。(走了这段未知的路，才变成了已知，每一段经历都值得纪念)
但是，恢复流程调用的是数据面容器提供的poweroff API，它做不到clean umount，最开始这个接口里面是延迟卸载，即挂载点先卸载，数据后刷盘，后来把这个怀疑点跟数据面澄清后，他们修改了一版，重新验证，还是不能够clean umount。
于是又怀疑是不是fence的第一个分区有影响从理论上讲，一个是第一个分区，一个是第三个分区，不应该有影响，但也不能完全代表实际上就是这样，还能干嘛，已经无路可走了，有个怀疑点就干呗，于是把第一个分区变量的值从第一个分区盘符改为容器里面的一个路径，经过验证，resize2fs仍然失效(即journal里面的数据并未刷干净)。
最后的最后，实在是没有其他办法了，我又看了一遍扩容流程的代码和备份流程的代码(为了攻关这个问题，已经不知道看了几遍了。。)，发现扩容流程是stop，备份流程是poweroff。
于是，和数据面的两个同事又一番讨论，我说，这是最后一根救命稻草了，能怀疑的都怀疑了，该验证的也都验证了，如果还不行，我是真的没辙了。
周三了，他们都准备下班回家了，讨论时都已经背好包了，路过我工位不由得就又展开了一番讨论(已经不知道第多少次讨论了)，说完后，我准备做最后的验证。
中间探索了很多怀疑点，经历了很多假设验证，都一一被否定，最终已经无路可走时，才柳暗花明，但仍然未水落石出。
皇天不负有心人，终于，停止容器可以把journal刷干净。
那么，就把poweroff改成stop容器吧。
问题暂时得到解决。
但是这个问题解决的不那么漂亮，基本上是一种没有更优解决方案时的解决方法。
因为，stop容器有点暴力，而且它还会带来一个副作用，在集中备份的那个时间段对k8s的压力会陡增。
其实，这都不算啥，还没有触到痛点(HA本来就是一个基本能力，也借这次改为stop的契机，生产环境验证了一把"小"规模HA，从结果看，好像没那么理想)，最大的痛点是告警组件，告警组件会调用容器里面提供的一个status REST API，当容器stop时，这个调用会失败，告警组件就会触发一大批告警。此时，我们的SRE就不同意了，于是回退到poweroff，继续探索unclean umount的根因。(后来，告警组件方案大变动，下放到租户机器，也不算是痛点了，还有一点当时的告警组件比较简陋，也没有在一定时间内有重试机制，痛点的本质是大规模HA，当然，这是后话。)
当你经历了"千辛万苦"找到了一个非常不同寻常的问题的解决方案，却又引起了众多微服务项目中的另外一个微服务的问题，这个方案就自然而然的被打成了临时方案，由于告警组件正在方案大改动，此时暂时维持现状，因此，短暂的两难，有了方案却不能施行，只能带着问题继续前行(好在这个问题不急，场景在研发角度算普通，但在用户很可能长时间都不会用到这个组合场景)。
网友评论