【PaperNotes】SOSP'17 DFSCQ，形式化验证crash-safe的文件系统

最新推荐文章于 2024-05-29 09:33:58 发布

原创

最新推荐文章于 2024-05-29 09:33:58 发布 · 453 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#形式化验证 #文件系统

DFSCQ是基于FSCQ的串行文件系统，增加了fsync和fdatasync接口以提高性能。文章介绍了这两个接口的原理，如何处理批处理系统调用和跳过日志写入带来的问题，以及如何通过形式化验证确保crash安全性。DFSCQ使用Hoare Logic和Separation Logic进行形式化验证，并在Haskell中实现。

预备知识

形式化背景（hoare logic、separation logic等），文件系统（inode，disk block等）

介绍

DFSCQ是在FSCQ基础上进一步的工作，FSCQ是用coq形式化验证后拥有crash-safe属性的串行文件系统，FSCQ对disk进行了建模，用coq规定了disk的行为，同时提出了crash hoare logic(CHL)这个能证明crash-safe的逻辑规则。DFSCQ在FSCQ的基础上，为应用额外提供了fsync和fdatasync两个接口，这两个接口通过batch data flush的方式提高了程序性能。

简而言之就是为了提高性能，需要额外证两个接口fsync和fdatasync，导致建模变复杂了，证明变麻烦了。

当然作者没有去证明ext4的正确性，而是自己写了一个DFSCQ，用coq证明其正确性，用coq生成haskell运行，并且DFSCQ是一个串行的文件系统，不支持并行，这两点成为了这篇论文的limitation。

Why fsync and fdatasync?

为什么我们要这两个接口呢，先介绍一下这两个接口分别是什么。

fsync和fdatasync都是文件系统提供的接口，fdatasync将文件的data部分刷入disk之后返回（保证返回后data部分数据不会因为crash丢失），fsync将文件的data与metadata部分都刷入disk。这两个接口是为了实现文件系统的高性能优化所准备的。

其中最核心的两个优化是：

batch syscall，用log的方式，打包syscall并执行，减少I/O，这时候为了保证crash一致性，需要应用主动调用fsync和fdatasync确保数据被刷入disk。
log-bypass writes，为了处理大文件修改的性能，不可能将大文件内容写入log一遍再写回数据本来在的地方，这样就相当于把文件写了两次，所以通常会在metadata commit后把数据in-place的直接写回。（因而会带来data部分其实是乱序写入disk的问题，crash会暴露中