谈一谈如何处理文件系统损坏的问题

在嵌入式的设备上，一个无法避免的问题是，如果设备突然掉电，可能会引起一系列的连锁反应(这也是PC不建议直接扣电池的原因)，其中有一项就是，突然掉电可能会引起文件系统损坏，这可是要命的！一般来说，如果只是文件损坏，那也没啥，最多坏一个或者几个文件，但要是文件系统损坏，那可能意味着所有数据的丢失(当然，如果你舍得花钱，还是可以找回来的， 只是成本问题)，对用户体验的影响会是致命的，我们要如何解决这个问题呢？

首先从测试说起：

测试： 选用FAT32文件系统，自己写脚本做写入文件时随机断电的压力测试，发现：

问题一：文件系统没有损坏，但最后写入的文件有一个或者多个损坏

问题二：文件系统损坏，比如文件系统变成read-only（最常见的问题），有时也会有文件系统损坏

分析：

针对问题一，有一下两种case可能造成多个文件损坏(我们能接受的只有最后一个file坏掉，但其他的file必须是好的)

Case #1： 一个物理的block可能包含多个文件系统的block file，这样造成写一个file的时候可能把不相干的file擦除，造成其他文件损坏。

Case #2： 一个物理的block可能包含多个文件系统的block file，这样造成写一个file的时候可能把不相干的file擦除，造成其他文件损坏。

针对问题二：

FAT32不是日志型文件，文件系统只是记录一些index，而且写入的时候没有备份，这就意味着，如果写index的时候断电，那文件系统可能就出问题。

解决方法：

针对Case #1：这个可以通过调整file system的block size来解决，确保一个block里面只放一个file，这就要求文件系统的block size必须大于或者等于存储介质的block size，而且必须是存储介质block size的倍数关系，一般我们设定成一样的即可。因为FS的block size越大，浪费也越严重。

针对Case #2：因为操作系统缓存的关系，在断电的瞬间还是可能造成多个文件损坏(因为这些文件缓存在内存)，但文件系统不会损坏。如果想避免出现多个file同事损坏，可以使用fsync()， fdatasync()函数在写完重要的数据后强制sync。

针对问题而，可以选中EXT4 文件系统，

EXT4是日志型文件系统，每次写入数据的时候，会先将meta data的部分写到一个back up区域，back up区域写完再往目标地址copy，这样：

   如果断电的时候back up区域没写完，重新开机后文件会找不到

    如果断电的时候back up区域已经写完，但是目标地址没写完，重新开机后系统会自动把back up区域的meta data copy到目标地址，从而找到文件

    如果目标地址也写完了，那文件自然没有问题。