2018年的最后一段时间，遇到了一个非常棘手的问题，我们的文件系统要定时备份，但这份备份中的数据还原时，文件系统(ext4)中的journal里面有脏数据，理论上非延迟umount可以搞定这个事情(即clean umount，不仅可以将缓存其他干净，还可以将journal刷干净)，谁知实际上"不是"(后来才解开这个疑惑，否则我们做文件系统的就要开始怀疑人生了)，后来，经历了很多的尝试，基本上都是我在黑暗中摸索，每一条路走投无路的时候找人讨论一下，继续尝试下一条思路。
下面举一个例子，这只是其中一条路，我们的文件系统是用户态的，并且，不仅仅是用户态的，而且还是运行在docker容器里面的。
我们经历了很多，走到这里，是基于这样的现象了，把容器stop掉之后，发现journal能够刷干净，但是走文件系统的poweroff之后(实际的动作是umount容器里的ext4的挂载点)，journal就有脏数据。
因此，我把现象概括描述了一下，post到了攻关小组里，有一位17j专家，提供了一条尝试思路，就是在容器里面在poweroff之后，先执行sync，再执行drop_caches，就是下面要说的了，请看:
1、sync
2、echo 3 > /proc/sys/vm/drop_caches
关于drop_caches文件：系统默认为0
drop_caches
Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.
To free pagecache:仅清除页面缓存（PageCache）
echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:清除目录项和inode
echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:清除页面缓存，目录项和inode
echo 3 > /proc/sys/vm/drop_caches
As this is a non-destructive operation and dirty objects are not freeable, the user should run `sync' first.
后记: 实际上问题并不在这里，因为，它不能解释一个简单的问题——既然容器里poweroff的时候ext4分区已经被umount了，唯一的引用点都被解藕了，sync和drop_caches又把缓存刷到哪里去了呢？！除非，umount并没有真正的把ext4分区umount掉，不对呀，进入到容器里查看，挂载点没有了啊。
那就是umount掉了，为了证明上面的那个简单的问题，如何才能证明呢？？
一条命令，iostat -xdm 1。
开多个命令行窗口，在每一个动作(三个动作poweroff、sync、drop_caches)执行的同时，监控落盘的io。
iostat是最粗粒度的监控落盘io，如果想进一步监控，比如哪个进程或者哪个文件的io，可以到网上搜一下，有方法，我也看到了，这里只提供一个思路，原来还可以这样，只不过对于我要证明的问题，iostat就够了。
iostat的监控结果:
poweroff有io落盘;
sync没有io落盘;
echo 3 > /proc/sys/vm/drop_caches没有io落盘;
到处，这一条路也就走到头了，又走投无路了。
那么，特么的journal里面的数据到底是哪里的呢？？？？？？？？
山重水复疑无路，柳暗花明又一村。
真真的是"车到山前必有路"，黑夜给了我黑色眼睛，我再一次进入到黑暗中摸索。
后来，事情的真相竟然有点让我喜极而泣，我们为了最小影响用户文件系统的卡io的时间(也就是poweroff到poweron的时间)，poweroff之后sleep 1秒之后就poweron了，殊不知这个时候底层备份的接口，快照还没有ok，就poweron了，journal里的脏数据就是这样来的。
跟备份的同事沟通，同样认为快照一般是很快的，但是1秒的时间不能保证，最好的方法是底层有个接口check，check快照ok之后再poweron。
长叹一口气，花费了我那么多的时间，不过也是有经验积累，算是工作经历中的一个难得的经历。
问题的答案往往在问题的相邻层面(德国某战略家)，但是只有你经历过千帆侧畔，你才能有这样的战略眼光，一下子看到问题的要害，一击必中。
网友评论