https://github.com/pellepl/spiffs/wiki/FAQ#how-long-will-my-spi-flash-live
如果你想在這里找到答案，請給我發郵件或在github上發帖。
為什么spiffs這么慢？
除了底層硬件（CPU和SPI閃存）之外，主要是因為spiff使用的內存很少。Spiffs不會在ram中構建任何文件樹，它實際上更像是一個暴力文件系統。一個人可以啟用緩存和東西，但它可能仍然很慢。spiffs中最慢的部分是文件系統完整性檢查SPIFFS_check。這是因為檢查必須使用少量字節交叉引用大部分信息。因此，它在整個文件系統上運行多次掃描。也就是說，在優化spiffs方面付出了很多努力，它不應該比它必須慢。
spiffs如何處理powerlosses？
存在用於更新數據的方案：當修改頁面時，舊頁面首先被標記為被修改，然后用更新的（並且可能未更新的）數據寫入新頁面。然后刪除舊頁面，最后將新頁面標記為已完成。如果某處出現斷電，可能會有兩個頁面具有相同的ID，但這些頁面的狀態將指示哪一頁有效。還有一些完整性測試，在訪問文件時總是會進行測試。如果可以修復問題，將盡可能嘗試這樣做。在spiffs的早期，在掛載時進行了完整的完整性檢查，但是由於花費了很長時間，我將其刪除了。現在必須由用戶調用它。
Powerlosses續：我SPIFFS_check什么時候應該跑？
檢查會修復損壞的文件，清除未引用的頁面，等等。一開始spiffs在mount上運行了。然而，在較大的閃光燈上，這變得太慢了 - 因此，檢查被置於其自身的功能中。
那么何時運行呢？如果SPIFFS_info回報used > total此外，獲得任何的錯誤代碼SPIFFS_ERR_NOT_FINALIZED，SPIFFS_ERR_NOT_INDEX，SPIFFS_ERR_IS_INDEX，SPIFFS_ERR_IS_FREE，SPIFFS_ERR_INDEX_SPAN_MISMATCH，SPIFFS_ERR_DATA_SPAN_MISMATCH，SPIFFS_ERR_INDEX_REF_FREE，SPIFFS_ERR_INDEX_REF_LU，SPIFFS_ERR_INDEX_REF_INVALID，SPIFFS_ERR_INDEX_FREE，SPIFFS_ERR_INDEX_LU，SPIFFS_ERR_INDEX_INVALID。
如果在啟動時可以檢測到功率損耗，那么決定是否運行檢查當然是一個很好的輸入。一些CPU具有備用電池RAM，可用於檢測電源斷電時是否正在運行spiffs。例如，可以在宏中設置一個電池反轉位SPIFFS_LOCK並清除它SPIFFS_UNLOCK。在啟動時，如果檢測到powerloss，並且如果設置了該位，則運行check。
此外，作為維護，檢查應該/可以在一年/每月/每周或至少一次運行至少一次。然后，它可能根本沒有必要 - 它取決於你，力量和應用程序本身。
在電池供電的系統上，我建議在充電期間運行它，如果電池電量高於某個水平。檢查當然也可以處理掉電，但是如果發現fs之上的任何錯誤在某種程度上是不一致的。
作為旁注，我想到了在fs中保留一個特殊的奇偶校驗頁面，其中一個位在開始一些spiffs操作時被清除，並在操作結束時清除另一個位。在安裝時，如果清除的位數不均勻，則應運行檢查。因為我有電池支持的ram，我從來不需要這個。但如果有人覺得非常需要這樣的檢查 - 如果我應該運行檢查功能，提出問題並開始煩我 - 它可能仍然會發生:)
緩存如何工作？
如果SPIFFS_CACHE啟用了構建時間配置，則spiffs會在讀取內容時使用ram中的閃存鏡像。如果SPIFFS_CACHE_WR禁用構建時配置，則所有寫入都是直寫。如果SPIFFS_CACHE_WR啟用，則還會緩存寫入。當調用的文件寫入高速緩存（如果有的話）被刷新SPIFFS_fflush，SPIFFS_close，SPIFFS_read，SPIFFS_fstat，SPIFFS_lseek。調用時刷新所有文件SPIFFS_unmount。這意味着例如SPIFFS_read可能會出現與寫操作有關的錯誤。
可以在i2c eeprom上運行spiffs嗎？
不。至少沒有i2c eeproms我遇到過。Spiffs廣泛使用nor flash寫法，其中寫入的字節是AND編寫的。例如，假設您的閃存上有一個字節被擦除，即為0xFF。如果您首先將0xFE寫入0xFF然后再寫入0x7F，則spiffs會將此字節讀取為0x7E。當然，人們可以為spiffs寫一個hal，它首先讀取應該寫入的內容，然后AND寫入內存，最后將這個ANDed數據存儲到i2c eeprom。考慮到i2c總線速度，性能會很糟糕。
為什么一半的測試在運行時失敗make test？
因為缺少文件夾。先跑make all。
我的SPI閃存會存在多長時間？
這取決於一切。但是，讓我們構建一個簡單的案例，我們不會過多地深入細節。
假設我們有一個1MB的閃存。只有一個文件。每一秒我們打開文件，讀取一個數字，遞增它，然后再次存儲文件。
假設我們將閃存划分為128字節頁面和64k塊。閃光燈在失敗前應對10000次擦除。
因此，我們將有1MB / 64k = 16塊。每個塊有512頁，一個文件更新將消耗兩個頁面（元數據+數據），這意味着我們可以在使用需要在重用之前擦除的完整塊之前執行512/2 = 256個文件更新。此外，spiff總是需要兩個空閑塊。
考慮到上述情況，在（16-2）* 256 = 3584文件更新之后，系統將充滿已刪除的頁面，並且需要擦除塊。此后，在每個第256個文件更新之后，必須擦除塊。由於我們有16個塊並且具有耗損均衡，因此在再次擦除相同塊之前將需要256 * 16個文件更新。這可以在事情失敗之前做10000次，所以總結起來我們可以在spi flash耗盡之前做3584 +（256 * 16）* 10000個文件更新，大約40960000次。為了安全起見，因為我們沒有考慮一些額外的元數據，我們乘以0.75（相當激進）我們總計達到30,700。
每秒一次寫入是355天。
另一方面，如果您的更新每分鍾發生一次，您可能會在58年內出現故障。
此外，今天的許多閃光燈在失效之前可以擦除100000次（或更多次），這將超過壽命10倍。查看數據表。
是否會保留文件列表順序？
當您在文件系統上列出文件時，順序是任意的。此外，由於垃圾回收，您可以在對文件系統進行任何更改后立即對其進行重新解密。如果文件的訂購很重要，則由用戶負責處理; 例如，通過文件名中的序列號。