十萬次掉電測試是怎樣煉成的？
少年，不得了了，出大事了！
“監(jiān)測了一個月的數(shù)據(jù)，昨晚碰上意外斷電，F(xiàn)lash盤里數(shù)據(jù)全沒了！怎么辦？”
“客戶設備意外停電，來電后Flash盤里的程序都沒了！怎么辦？”
“系統(tǒng)掉電后，flash盤里目錄全部變亂碼了！怎么辦？”
這些問題的罪魁禍首就是Flash文件系統(tǒng)不具備掉電保護特性。
數(shù)據(jù)安全日益重要，而文件系統(tǒng)卻依然我行我素不管掉電過程中文件的死活，這怎么能忍！
致遠不能忍！
不過光有一腔熱血是遠遠不夠的，解決問題還需進行全面細致的調研。Nand Flash在擦除和寫入過程中發(fā)生掉電在實際應用中是極有可能發(fā)生的，那么在NandFlash擦除/寫入時掉電會發(fā)生什么呢？為什么會造成如此惡劣的影響呢？下面我們來一一剖析。
以8位 SLC工藝的NandFlash寫操作為例，掉電時寫到怎樣就是怎樣。譬如寫入0x01 0x02 0x03 0x04,寫到0x03時斷電，此時FLASH中有如下可能：
如果是MLC結構，同樣寫到0x3，那可能結果就是：
理想很美好，現(xiàn)實很骨感，寫入0x03都能蹦出這么多種情況，實際應用中的突發(fā)掉電造成的結局就更千奇百怪了。那如果在文件系統(tǒng)中沒有相應的預防措施會發(fā)生什么慘案呢？
WinCE內核中，文件系統(tǒng)版本主要包括 exFAT，F(xiàn)AT32，F(xiàn)AT16，這幾個文件系統(tǒng)都不具備掉電保護功能。以FAT32文件系統(tǒng)為例，我們放慢鏡頭，仔細觀察在Flash寫操作過程中到底發(fā)生了什么。
上圖是FAT32文件系統(tǒng)讀取文件示意圖，簇是 FAT32 進行數(shù)據(jù)存儲的最小單位，文件按照鏈式結構存儲，F(xiàn)AT表項中存儲了下一個簇號，文件系統(tǒng)根據(jù)FAT表項中存儲的簇號獲取下一個簇，直至文件讀取完成。
現(xiàn)在我們向文件末尾添加一些數(shù)據(jù)，文件系統(tǒng)將會為文件分配新的簇，將FAT表項內容改寫為新的簇號，將新添加的數(shù)據(jù)寫入到下一簇號的數(shù)據(jù)區(qū)中，如此往復直至文件保存完成。
等等，說好的慢鏡頭呢？ 我們是不是錯過了什么？
鏡頭回到最開始，文件系統(tǒng)為文件分配新的簇，F(xiàn)lash對新分配的簇進行擦除操作，完成后寫入新的數(shù)據(jù)內容。完成數(shù)據(jù)塊的寫入后，改寫FAT表項內容為下一個簇號，如此往復直至文件全部保存完成。
那么問題來了，如果在寫入數(shù)據(jù)塊過程中發(fā)生斷電，F(xiàn)AT表還沒來得及更改，那是不是就意味著新修改的內容沒有被保存？回答是肯定的，當然這也是最幸運情況之一了，因為并沒有對原文件造成損壞，只是丟失了新添加的內容而已。
如果掉電恰好發(fā)生在操作FAT表、目錄區(qū)呢，是不是有毛骨悚然的感覺？
WinCE默認的文件系統(tǒng)面對突發(fā)的掉電這么無助，難道我們只能袖手旁觀？
不！
致遠WinCE平臺為了支持文件系統(tǒng)掉電保護功能，在文件系統(tǒng)中加入了TFAT特性，同時在驅動中添加掉電保護功能代碼。為了驗證TFAT特性和掉電保護功能代碼的實用性，我們?yōu)閃inCE平臺量身打造了Flash掉電測試方案。
使用智能定時器控制被測設備電源，使用測試軟件A監(jiān)測文件系統(tǒng)狀況，測試軟件B進行數(shù)據(jù)拷貝操作，在拷貝過程中對設備隨機斷電，如此往復以模擬Flash寫入時掉電，軟件運行流程如下圖所示。
寶劍鋒從磨礪出，梅花香自苦寒來，經(jīng)過一個月漫長的測試，測試次數(shù)約達10~12萬次，若未出現(xiàn)失敗信息則可為該平臺發(fā)放Flash掉電測試通過許可證，自此仗劍走天涯！
