少年，不得了了，出大事了！

“监测了一个月的数据，昨晚碰上意外断电，Flash盘里数据全没了！怎么办？”

“客户设备意外停电，来电后Flash盘里的程序都没了！怎么办？”

“系统掉电后，flash盘里目录全部变乱码了！怎么办？”

这些问题的罪魁祸首就是Flash文件系统不具备掉电保护特性。

数据安全日益重要，而文件系统却依然我行我素不管掉电过程中文件的死活，这怎么能忍！

致远不能忍！

不过光有一腔热血是远远不够的，解决问题还需进行全面细致的调研。Nand Flash在擦除和写入过程中发生掉电在实际应用中是极有可能发生的，那么在NandFlash擦除/写入时掉电会发生什么呢？为什么会造成如此恶劣的影响呢？下面我们来一一剖析。

以8位 SLC工艺的NandFlash写操作为例，掉电时写到怎样就是怎样。譬如写入0x01 0x02 0x03 0x04,写到0x03时断电，此时FLASH中有如下可能：

如果是MLC结构，同样写到0x3，那可能结果就是：

理想很美好，现实很骨感，写入0x03都能蹦出这么多种情况，实际应用中的突发掉电造成的结局就更千奇百怪了。那如果在文件系统中没有相应的预防措施会发生什么惨案呢？

WinCE内核中，文件系统版本主要包括 exFAT，FAT32，FAT16，这几个文件系统都不具备掉电保护功能。以FAT32文件系统为例，我们放慢镜头，仔细观察在Flash写操作过程中到底发生了什么。

上图是FAT32文件系统读取文件示意图，簇是 FAT32 进行数据存储的最小单位，文件按照链式结构存储，FAT表项中存储了下一个簇号，文件系统根据FAT表项中存储的簇号获取下一个簇，直至文件读取完成。

现在我们向文件末尾添加一些数据，文件系统将会为文件分配新的簇，将FAT表项内容改写为新的簇号，将新添加的数据写入到下一簇号的数据区中，如此往复直至文件保存完成。

等等，说好的慢镜头呢？ 我们是不是错过了什么？

镜头回到最开始，文件系统为文件分配新的簇，Flash对新分配的簇进行擦除操作，完成后写入新的数据内容。完成数据块的写入后，改写FAT表项内容为下一个簇号，如此往复直至文件全部保存完成。

那么问题来了，如果在写入数据块过程中发生断电，FAT表还没来得及更改，那是不是就意味着新修改的内容没有被保存？回答是肯定的，当然这也是最幸运情况之一了，因为并没有对原文件造成损坏，只是丢失了新添加的内容而已。

如果掉电恰好发生在操作FAT表、目录区呢，是不是有毛骨悚然的感觉？

WinCE默认的文件系统面对突发的掉电这么无助，难道我们只能袖手旁观？

不！

致远WinCE平台为了支持文件系统掉电保护功能，在文件系统中加入了TFAT特性，同时在驱动中添加掉电保护功能代码。为了验证TFAT特性和掉电保护功能代码的实用性，我们为WinCE平台量身打造了Flash掉电测试方案。

使用智能定时器控制被测设备电源，使用测试软件A监测文件系统状况，测试软件B进行数据拷贝操作，在拷贝过程中对设备随机断电，如此往复以模拟Flash写入时掉电，软件运行流程如下图所示。

宝剑锋从磨砺出，梅花香自苦寒来，经过一个月漫长的测试，测试次数约达10~12万次，若未出现失败信息则可为该平台发放Flash掉电测试通过许可证，自此仗剑走天涯！