[linux][bcache]bcache导致的xfs文件系统错误问题分析

前言： 频繁见到xfs报错，文件系统出现了破损。 目前有两种情况下使用xfs： 其一，在物理机上使用启用了bcache的blk设备，格式化成xfs直接使用，这种情况下，运行过很久，都没有出现问题； 其二，在物理机上，使用scsi passthrough技术，把磁盘都passthrouge给虚拟机，在虚拟机内部启用bcache，格式化成xfs，运行不久，虚拟机里面就会出现xfs的文件系统破损。 分析： 1，xfs文件系统破损 基于上述问题的描述，在物理机上长期使用xfs，没遇到问题，可以基本判断出来，当前的kernel和xfs的版本，是稳定的。所以，很可能是出现在虚拟机环境上。 xfs带有日志，如果日志的数据被改错，最容易出现xfs报出来的故障。最常见的错误就是，两台虚拟机同时使用块设备，典型的例子就是把一个卷同时挂载给两个虚拟机，虚拟机跑一会，几乎问题必现。但是，这种情况被排除了，因为这几块磁盘已经passthrough给唯一的一台虚拟机了。 还有一种可能，就是物理机上，还有其他的进程或者线程，修改了磁盘的数据。重点来分析这种情况。 2，架构

对于passthrough的情况，是右侧的直接使用driver的场景。 如果物理机上有进程修改了磁盘的数据，就要排查另外两种情况的使用。 对于使用vfs的情况，一定要mount具体的文件系统才行。通过执行mount命令，依次查看。出现问题的磁盘都没有被mount过，这种情况排除。 对于访问/dev/sdx的裸设备的方式，使用脚本，对所有进程执行lsof，查看所有进程的打开的文件。这种情况也排除。 那么，还剩下一种隐藏的情况，就是有内核线程在偷偷的搞事。逐个看内核线程，最后发现，最有可能的是bcache线程。 3，bcache

hdd在guest中被添加成为bcache类型的磁盘，实际操作是向hdd盘的header中写入bcache的magic。在host上，磁盘被加载的时候，同样可以扫描到bcache类型的header。在systemd-udevd和kernel的共同配合下，会加载bcache.ko，被启动bcache内核线程。那么就会出现上图的情况：host已经把磁盘passthrough给了guest，本身是不想管理磁盘的，但是host还是启动了bcache内核线程，在host和guest中，各自有内核线程向hdd中写入数据，而且互相不感知。最终，导致hdd中的数据异常，被guest中的xfs发现，报出来了文件系统错误。 4，disable bcache 解决办法很简单，在host上禁用bcache就行了。 查看bcache代码，没有找到控制开关可以关闭bcache，也就不能通过kernel cmdline传递参数了。 systemd-udevd没有二外的启动参数，看起来不能配置。（这里到底能不能，作者也很想知道） 删掉/lib/modules/`uname -r`/kernel/drivers/md/bcache，是很干净的做法。 5，ramdisk 删掉/lib/modules/`uname -r`/kernel/drivers/md/bcache之后，重启host，执行lsmod | grep bcache还是看到了bcache被加载到了kernel。 在操作系统中find之后，已经找不到bcache.ko了。

在kernel中加一些log（如图，大括号里面是新增加的debug代码），最终，确定是systemd-udevd加载了ramdisk中的bcache.ko。

解压ramdisk，重新编辑，再打包，问题得到解决。