题外话
《邪不压正》这部电影刚上映我就去看了，作为姜文的民国三部曲最后一部，刚上映就把《我不是药神》挤下神坛，但我不关心票房，单纯是冲着他的上部电影《让zidan飞》的精彩剧情和台词，抱着美好的期待去的。
走出电影院，我就忘了讲的是啥，只记得彭于晏在老北京的屋檐上到处乱窜，整部剧情就一个少年复仇记的简单故事，台词晦涩难懂、剧情跳跃、人物形象也不完整。远远没有当年观看《让zidan飞》的惊艳体验。
还记得《让zidan飞》里姜文饰演的张麻子一出场就密集的打出7枪：
六子:没打中？
张麻子：让zidan再飞一会儿
这句话从张麻子口中说出，透出无比的自信，想表达的意思就是：别急着要结果，好事正在酝酿中。
1 背景
言归正传，现如今我们使用云计算产品，无论虚拟机是linux，还是windows系列的操作系统，云硬盘挂载到云主机，再经过文件系统格式化，是最常用的存储使用场景，相当于我们家用计算机的D盘、E盘，用来存放数据、安装软件等。
对硬盘的操作，有一点可以达成共识的是，在Linux系统下，对磁盘分区的处理，通常都是采用fdisk、mkfs的处理方式，当然大于2TB的磁盘另外，不在本次讨论范围内。
整篇文章分以下几小章节：
1 、背景
2 、现象回顾
3、 云硬盘挂载后，ceph后端存储实际如何变化
4 、centos不同内核下的表现
5、 找到根本原因
6、 总结
2 现象回顾
有几次在格式化云硬盘并mount后，很快执行fio测试发现和历史数据对比性能有所下降，回过头对ceph节点osd io进行监控时，观察到1个现象，即执行格式化、创建文件系统后短时间内磁盘会产生数分钟写io。
mount云硬盘之后，写操作持续了5分钟以上，时间有点久，在这个时间内，如果对云硬盘执行大吞吐的读写操作，或多或少影响的实际的性能，甚至是否会影响数据持久化，不得而知，因此不得不花了些时间排查具体是什么原因触发的。
3 云硬盘挂载后，ceph后端存储实际如何变化
分了几个步骤对云硬盘从创建开始，到写入数据的所有过程做个梳理，看看是哪些环节产生什么样的反映。
（1）新建的volume无任何数据
Cinder创建 100GB的数据盘，卷类型为无qos，此时在rbd 的custmized-hdd池中，出现了刚刚创建的volume，通过rbd diff计算这个volume实际占用容量为0，无数据
（2）云硬盘挂载到云主机，但不分区
将100GB的volume通过nova volume-attach挂载到云主机，但不安装ext4文件系统
此时数据盘无读写io，rbd 的custmized-hdd池中的volume仍然没有数据，4个节点的osd无写io现象
（3）格式化云硬盘并mount
格式化/dev/vdb为ext4，不挂载，此时rbd 的custmized-hdd池中的volume增加大约140MB的数据
再将数据盘挂载到/mnt上，出现写io，osd和云硬盘盘都监控到有写的吞吐，持续大约5分钟停止，平均吞吐在5MB/S-7MB/S，产生的数据总和为=300秒*5MB=1500MB左右
查下存储池该volume是否真增加这么多数据？检查rbd 的custmized-hdd池中的volume，仍然使用rbd diff计算这个volume实际占用容量，发现增加了1.5GB的数据，总容量到1743B，如下图
再和object总数做个核对，Rbd下该卷存在498个object，以4MB一个计算总和不到1.9 GB，考虑到volume刚创建时，前期的object不满4MB，和rbd diff计算得出基本一致，如下图：
看完云硬盘挂载到虚拟机后，ceph底层存储的一系列表现，我们不妨停下来思考一下，整理思路：
（1）Mount云硬盘之后，写操作持续了5分钟，是实实在在的在存储池下产生数据的，这一点得到证实
（2）因为我使用的centos7.2系统，mount后会产生写操作，是不是linux的特性，需要在centos6.5上再证实一下
4 centos不同内核下的表现
增加在cenots6.5下执行同样的挂载云硬盘、格式化和mount操作的测试场景，看是否存在同样的数分钟持续写情形。
（1）排查mkfs的差异
cenots6.5的vm格式化100GB云硬盘并mount，前期准确过程略，从mkfs开始，cenots6.5在mkfs过程中，当执行到Writing superblocks and filesystem accounting information，明显要比cenots7.2要慢很多，cenots7.2执行这个操作是1秒左右，而cenots6.5需要40秒以上。
（2）验证mount后的云硬盘读写
使用cenots6.5创建vm，挂载100GB数据盘并mount后，也存在写io，但时间很短，大约十秒的时间
了解了不同内核的os在执行格式化文件系统的差异，我们再次停下来思考一下，整理思路：
（1）从上面的“排查过程二”下的第（2）步骤，初步得出一个是mkfs时一起写入io，一个是mount后再写入 ，应该是在Writing superblocks and filesystem accounting information过程中存在的差异
（2）Centos7.2、Centos6.5在mount云硬盘后存在写io的差异，有点奇怪了，需要排查下是哪个进程在写
5 根本原因浮出水面
通过iotop查询vm中进程的读写io实时数据，排查下Centos7.2、Centos6.5的差异到底在哪。
前期准备不再反复描述，我们直接观察两个阶段的写情况，一个是mkfs过程，一个是mount后
（1）找到Centos7.2是哪个进程在写
因为Centos7.2的Mkfs秒级操作，iotop显示mkfs时写实时吞吐为54MB/S，再从云硬盘mount后开始，在vm中执行iotop后发现Centos7.2 上只有ext4lazyinit进程存在io写，实时吞吐为7MB/S，如下图
（2）找到Centos6.5是哪个进程在写
Centos6.5是在mkfs时有点慢，在vm中执行iotop后发现Centos6.5 上是mkfs进程存在io写，实时吞吐为58MB/S，如下图
很明显，Centos7.2、Centos6.5在mkfs、mount云硬盘过程存在写io的差异
ext4lazyinit，直译为ext4惰性初始化，通过调研在cenots7以后，内核3.10之后，操作系统对格式化分区是通过ext4lazyinit实现，好处就是能迅速的创建文件系统，会把文件系统初始化的工作推迟到挂载后进行。
这样一来对于用户感官来说，格式化云硬盘速度非常快，体验很棒。但这样的情况，就需要再mount之后，最好是等待数分钟之后再操作硬盘分区。
总结
前文说到在cenots7以后，内核3.10之后，在格式化分区上流程的变更，带来用户体验的优化。
需要注意的是，文件系统惰性初始化时间是根据云环境的网络、磁盘qos综合衡量，并不固定。并且对于操作系统的使用者来说属于黑箱，你唯一能做的，就是让磁盘冷静会，特别是性能评估，就需要在mount之后等待数分钟后再执行，防止数据的不准确。
值得一提的是，在cenots7更新之后，带来一些新的特性，对应其他性能上也会带来提升，如下表中：
Systemd的作用其实不新鲜了，早在2015年时我在中科院软件研究所从事国产操作系统研发时就实际应用过。
以往在linux各种发行版本中，采用这种方式的并不多，linux各种服务器版本给用户带来的性能提升并不明显，但如果加载到centos桌面版，会有明显的感官，从启动系统到完成桌面加载的时间变快了，谁不希望打开系统的时间越短越好呢，但也有弊端，增加了xorg崩溃的风险。
更高性能的KVM内核虚拟化支持，减少了云平台上层到底层的io链路，理论上应该能对虚拟化资源的响应带来性能优化，目前还没有对此做过比较，后续再跟踪。