文件系统崩溃一致性、方法、原理与局限如何解决？

liwen01 2024.06.16 前言 先提几个问题：什么是文件系统崩溃一致性？为什么会出现文件系统崩溃一致性问题？有哪些方法可以解这个问题？它们各自又有哪些局限性？ window系统电脑异常后会蓝屏、手机死机卡顿后我们会手动给它重启，大部分设备的系统在遇到不可修复的严重异常后都会尝试通过重启来恢复，因为系统重启之后，系统整体比较"干净"。 其中有一例外，就是我们希望磁盘存储的数据无论在系统出现何种异常的情况下，都能够保存好原来的数据，系统恢复后可以再找到异常前的所有数据。 文件系统崩溃一致性(Crash Consistency)是指在文件系统发生崩溃、断电或其它不可预见的故障后，文件系统能够保证数据的一致性和完整性，并能够恢复到一个合法且可操作的状态，确保系统重新启动或恢复之后，数据不会出现损坏、丢失或不一致的情况。 (一)一致性的复杂性 以ext4 文件系统举例，当我们创建一个文件系统的时候，有下面4个步骤： 查找空闲 inode：通过检查 inode bitmap找到一个空闲的 inode，并在 inode bitmap中标记为已使用。 分配数据块：通过检查block bitmap找到空闲的数据块，并在block bitmap中标记为已使用。 更新 inode：将新文件的元数据写入 inode table中的相应位置。 更新目录项：在目标目录的 inode 数据块中添加一个新的目录项，包含文件名和对应的 inode 号。 因为磁盘是以扇区为最小单位，所以上面4个步骤不可能一次全部写入到磁盘中去，在1到4步骤中间的任意一个时间点系统突然崩溃，都会导致文件系统不一致。比如在2~3步骤中间断电，就会造成inode bitmap、block bitmap中标记已经使用，但是没有实际的文件与之对应，如果不回收，那么这几个块就可能永远不会被使用。 在实际使用的时候，情况会更加地复杂，因为系统为了提升文件系统的读写检索性能，在挂载文件系统的时候，系统会将文件系统的元数据缓存到内存上。如下图《图1.1 内存与存储结构》 图1.1 内存与存储结构 在有缓存的情况下，数据一般是定时写入磁盘，或者是手动保存才会写入磁盘，一次完成批量数据的写入。如果在这个过程中突然异常，丢失的数据可能会更加多。 有多少人经历过电脑突然断电，辛辛苦苦写的内容全部被丢失。系统崩了，内心也崩了。 关于ext4 文件系统的详细介绍，可以查看文章《文件系统(六)：一文看懂linux ext4文件系统工作原理》 解决文件系统一致性的问题，常用的方法有：日志、写时复制、Soft Update、日志文件系统，它们各有优缺点，目前并没有哪种方案可以适用所有场景。 (二)文件系统日志 (1)日志工作原理 在ext4文件系统中，有一个独立的日志数据区，它的基本思想是：先将一组操作记录到日志区(日志提交完成)，然后再去实现这些操作(应用事务完成)，实现结束之后再把日志擦除(日志清理完成)。 日志处理时序流程图 事务开始:文件系统开始一组更新操作，并开启一个新的事务 收集日志:收集所有即将修改的数据(以及在 Journal 模式下的数据) 提交日志:更新日志头，标记该事务已经提交(commit) 应用事务:将日志中的修改应用到文件系统，将数据和元数据写入最终位置 清理日志:事务完成后，日志系统清理已提交的日志记录 (2)通过日志进行恢复 文件系统有了日志功能之后，在文件系统崩溃或是突然断电后就可以通过日志保持文件系统的一致性。基本的流程是，文件系统挂载后，系统会去扫描日志区域，看是否有未完成的事务，如果有，则判断该事件是否有提交： 如果未提交，本次修改操作就直接丢弃 如果有提交，根据日志记录的信息，重新执行修改操作 日志恢复流程 (3)优缺点 文件系统的日志功能，它的主要优点有两个： 可以保持一致性：不会因为某些异常导致整个文件系统异常 可以减少文件系统检查时间：传统使用fsck去扫描整个磁盘进行检查，非常耗时，有了日志功能后，直接扫描日志信息就可以了。 文件系统引入日志之后，明显的缺点有： 影响性能：所有的操作都需要先写日志，再执行具体的操作，在高负载的情况下会导致IO压力增加，从而降低系统的整体性能。 写热点:因为日志区会频繁的写入和擦除，对于有擦写次数限制的flash来说，比较容易把日志区域写穿。 (4)ext4 的日志模式 ext4 文件系统用JBD2实现的日志有三种模式：Writeback、Ordered、Journal Writeback模式： 在这种模式下，元数据变更会被记录到日志中，但数据的变更不会被记录。数据写入磁盘的顺序不受元数据更新的顺序影响。