十萬次掉電測試是怎樣煉成的？
少年，不得了了，出大事了！
“監測了一個月的數據，昨晚碰上意外斷電，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掉電測試通過許可證，自此仗劍走天涯！
