文件系统和裸块设备的page cache问题

注：本文代码基于linux-3.18.31，此版本中块缓存已经合入页缓存。

本文来源于wowotech：http://www.wowotech.net/filesystem/439.html

普通文件的address space

文件系统读取文件一般会使用do_generic_file_read()，mapping指向普通文件的address space。如果一个文件的某一块不在page cache中，在find_get_page函数中会创建一个page，并将这个page根据index插入到这个普通文件的address space中。这也是我们熟知的过程。

块设备的address space

但是在读取文件系统元数据的时候，元数据对应的page会被加入到底层裸块设备的address space中。下面代码的bdev_mapping指向块设备的address space，调用find_get_page_flags()后，一个新的page（如果page不在这个块设备的address space）就被创建并且插入到这个块设备的address space。

两份缓存?

前面提到的情况是正常的操作流程，属于普通文件的page放在文件的address space，元数据对应的page放在块设备的address space中，大家井水不犯河水，和平共处。但是世事难料，总有一些不按套路出牌的家伙。文件系统在块设备上欢快的跑着，如果有人绕过文件系统，直接去操作块设备上属于文件的数据块，这会出现什么情况？如果这个数据块已经在普通文件的address space中，这次直接的数据块修改能够立马体现到普通文件的缓存中吗？

答案是直接修改块设备上块会新建一个对应这个块的page，并且这个page会被加到块设备的address space中。也就是同一个数据块，在其所属的普通文件的address space中有一个对应的page。同时，在这个块设备的address space中也会有一个与其对应的page，所有的修改都更新到这个块设备address space中的page上。除非重新从磁盘上读取这一块的数据，否则普通文件的文件缓存并不会感知这一修改。

实验

口说无凭，实践是检验真理的唯一标准。我在这里准备了一个实验，先将一个文件的数据全部加载到page cache中，然后直接操作块设备修改这个文件的数据块，再读取文件的内容，看看有没有被修改。

为了确认一个文件的数据是否在page cache中，我先介绍一个有趣的工具---vmtouch，这个工具可以显示出一个文件有多少内容已经被加载到page cache。大家可以在github上获取到它的源码，并自行编译安装

https://github.com/hoytech/vmtouch

现在开始我们的表演：

首先，我们找一个测试文件，就拿我家目录下的read.c来测试，这个文件的内容就是一些凌乱的c代码。

接着运行vmtouch，看看这个文件是否在page cache中了，由于这个文件刚才被读取过，所以文件已经全部保存在page cache中了。

然后我通过debugfs找到read.c的数据块，并且通过dd命令直接修改数据块。

修改已经完成，我们看看直接读取这个文件会怎么样。

文件依然在page cache中，所以我们还是能够读取到文件的内容。然而当我们drop cache以后，再读取这个文件，会发现文件内容被清空。

总结

普通文件的数据可以保存在它的地址空间中，同时直接访问块设备中此文件的块，也会将这个文件的数据保存在块设备的地址空间中。这两份缓存相互独立，kernel并不会为这种非正常访问同步两份缓存，从而避免了同步的开销。

---

查看我们精华技术文章请移步:

扫描下方二维码关注"Linux阅码场"

感谢您的耐心阅读，请随手转发一下或者点个“在看”吧~