本文主要是介绍【我悟了】异常断电导致的文件系统变为只读——案例分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
背景
应领导要求，临时支持其他项目上遇到的一个问题。由于该问题属于未涉及的知识领域，从接触到最终给出方案，也花了我不少精力。在此进行分享，主要介绍在面对不熟悉的问题领域时，分析问题的思路。希望能够给年轻的同学一点参考意义。
思路
问题现象
OTA 下载流程中，手动断开电源，再次重启，会发现OTA 程序运行异常，其原因是OTA 写文件的目录，变成了read_only。
经验一：切记！切记！切记！ 一定要先与先前直接负责同事进行充分沟通，尽可能的了解背景以及听取他分析思路。
通过与夏工交流，得到以下信息：
-
文件系统的挂载是由系统执行。我们并没有修改权限操作。
-
下载过程中，会涉及到频繁的文件读写，且这些文件是在该文件系统中。
经验二：善于关联，比较。与之前的项目经验进行对比。
针对客户的异常测试用例"OTA 下载流程中，手动异常断电"，其实很常见。因为我们其他项目中，基本都会有类似的测试用例，但一直没有出现过该问题。所以我在思考两者有什么不同？
经过查找咨询。发现一个明显区别：以往项目中，OTA操作的文件系统，基本都是ext4类型，而出现该问题的文件系统是fat32类型。
综上所述，目前我比较怀疑两个点：
ext4 和fat32文件系统有什么差别?
程序中对文件的操作是否有不合规的地方？
分析
一. 走读代码
通过与同事沟通和走读代码，OTA 流程中文件操作的流程大致如下：
由上图所示：
tree.xml文件的作用是记录OTA 流程中各个阶段信息。比如任务信息，下载阶段各文件的信息等。
OTA 流程中会记录当前阶段，用于下次继续任务。因此会涉及到频繁写入数据。本方案中采用的是tmp文件方式。
-
先读取
tree.xml信息，获取当前OTA 上下文。 -
根据OTA 进程，修改上下文。
-
写入
tree_bak.xml,再通过rename 替换 当前tree.xml。
该方式的优点：可以避免写文件时异常，导致OTA上下文丢失。因为rename 仅会修改文件node 信息，不会再对文件数据修改。
因此读写文件的操作也属于常规操作，并没有什么不妥。
二. fat文件系统和ext4文件系统区别
在I/O性能优化——这一篇就足够啦-CSDN博客文章中，我们知道，linux 支持不同的文件系统，而文件系统的实质就是帮助用户如何有效的利用磁盘上的空间以及文件管理。不同的文件系统其文件管理方式以及磁盘分配方式不同。这里不再赘述两者的异同。
Fat文件系统曾是windows 中主流文件系统，它最大的优点就是兼容性。大部分操作系统都支持。
ext4是在ext3基础上优化而来，具备很多优点。
-
支持在线检查和碎片整理。提高文件系统的可用性和性能
-
支持文件系统级别的加密和压缩功能。更好的保护数据安全性和存储效率
-
能够在异常情况下，更快的恢复文件系统。具有很好的可靠性。
由于客户的使用场景，该磁盘块需要被android 操作系统 和 QNX 操作系统挂载使用。因此只能选择fat32文件系统，（QNX不支持ext4）。
三.文件系统的临界区
我们知道文件系统对文件的管理分为两个部分文件数据+文件元数据。前者用于保存文件的原始数据内容，后者用于记录文件存储扇区，权限，大小，文件名等信息。若两者信息对不上或损坏则会出现异常。
因此在真正写磁盘时，就会出现一个临界区：如何保证文件数据和文件元数据的完整性和统一性。比如：
当执行上述红色代码时，出现异常终止，正在执行的对象可能会丢失（rename 的原理，只是修改两个文件的inode）。黄色代码时，出现异常终止，则有可能出现以下情况。
-
正在改写的文件数据被损坏，f_write
-
添加的文件恢复到初始状态,f_open,f_close
-
丢失新建的文件,f_open
-
新创建的文件或者覆写的内容丢失,f_open,f_mkdir,f_close
-
由于丢失簇链，磁盘性能下降,f_unlink
注：若以只读方式打开文件，则不会出现上述情况。
因此为了减少临界区，可以牺牲一些效率，减少临界区的大小。如下：
f_sync的功能是确保文件fd所有已修改的内容已经正确同步到硬盘上，该调用会阻塞等待直到设备报告IO完成。
综上所述，即使减少了临界区的大小，还是会存在文件系统错误的情况。
文件系统损坏的根本原因在于写文件不是原子操作，因为写文件涉及的不仅仅是用户数据，还涉及元数据，其中任何一个步骤被打断，就会造成数据的不一致或损坏。
四.日志文件系统
日志文件系统就是为了解决上述问题而应运而生。它的原理就是：在进行写操作之前，把即将进行的各个步骤记录下来，保存在文件系统上单独开辟的一块空间上，这就是所谓的日志。日志保存成功之后，在进行上述真正的写文件操作，把文件数据和文件元数据写入磁盘。异常断电就会存在两个场景。
-
在写日志时，异常断电，导致日志不完整。解决方式：丢弃本条日志，文件数据区不会影响。
-
在写文件时，异常断电，导致文件系统相关数据异常。解决方式：将之前保存的日志，再执行一遍即可。
而ext4具备日志文件系统属性，fat32并不具备。
解决方式
根据以上分析，建议客户进行以下途径尝试。
更换文件系统
更换文件系统，相对于我们是比较简单的。基本不会涉及到应用修改的成本。对于客户有些困难。因为该磁盘不仅要被android系统挂载使用，并且还被被QNX系统挂载使用。而QNX 仅支持FAT32和qnx6文件系统（可能是客户版本问题，若要支持ext4文件系统，需要加钱）---- 需要增加成本，并且底层估计还要适配。
开启磁盘修复
设备启动时，首先对fat32文件系统进行修复，再进行挂载。该方案整体成本应该是最少的，但是对于文件系统出错的类型，是否一定能修复完成，并不能保证。需要用大量测试进行验证。--- 修改成本最低，但是存在隐患，需要持续关注。
断电保护
客户提供断电保护机制。出现异常时，进行资源回收，文件系统正常卸载等操作。---- 最为保险，但是成本和开发能力要求较高。
总结
综上所述，希望通过该案例对大家有所帮助。遇到不熟悉的问题域时，不要慌张，静下心来，抓住每一个细节，进行回想，分析，讨论。
参考文献
深入解析Ext2/3/4文件系统
FatFs模块系统应用指南_fatfs f_sync-CSDN博客
日志文件系统工作原理_日志文件系统原理-CSDN博客
这篇关于【我悟了】异常断电导致的文件系统变为只读——案例分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
