SPIFFS は組み込みターゲット上の SPI NOR フラッシュ デバイス向けのファイル システムです。ウェアレベリング（書換限度回数が存在する媒体で使用寿命を延ばすためにデータ書換えを媒体中の記憶素子にできるだけ均等に分散させる手法）やファイルシステムの一貫性チェックなどをサポートします。
※NAND型とNOR型の違い
NOR型フラッシュメモリも不揮発性メモリの一種で、NAND型より先に生まれたデータストレージです。ランダムアクセスの読み出し速度はNAND型よりも優れていますが、書き込み速度は遅く大容量化に適さないという特徴があります。NAND型とNOR型の違いのひとつが、配線の接続方式です。NAND型もNOR型も、基本的なメモリセルの構造は同じですが、NAND型はメモリセルを直列に、NOR型は並列に配置しています。データへのアクセス方式も、NAND型とNOR型では異なります。メモリセルを直列につないでいるNAND型は、データのある場所を求めて端から順にアクセスしますが、並列に配置したNOR型はデータのある場所にピンポイントで直接アクセスができます。NOR型のほうがランダムアクセスの読み取りが高速にできるのは、このためです。その一方で、NOR型のメモリセルにはソース線を配線する必要があります。これに対してNAND型は、ソース線を複数のメモリセルで共有でき、空いた領域で多くのメモリセルを配置できるため、データの書き込みが速く、高集積化・大容量化にも向いている特徴があります。
１．現在、SPIFFS はディレクトリをサポートしておらず、フラットな構造を生成します。
SPIFFS が の下にマウントされている場合/spiffs、パスを使用してファイルを作成すると、ディレクトリ ではなく、SPIFFS 内に/spiffs/tmp/myfile.txtというファイルが作成されます。/tmp/myfile.txtmyfile.txt/spiffs/tmp
２．リアルタイム スタックではなく、1 つの書き込み操作には、他の書き込み操作よりもかなり長い時間がかかる場合があります。
３．現時点では、不良ブロックの検出や処理は行われません。
４．SPIFFS は、割り当てられたパーティション領域の約 75% のみを確実に利用できます。
５．ファイルシステムのスペースが不足すると、ガベージ コレクターはファイルシステムを複数回スキャンして空きスペースを見つけようとします。必要なスペースによっては、書き込み関数の呼び出しごとに最大数秒かかることがあります。これは SPIFFS の設計が原因で、この問題は複数回報告されています (例:こちら)。また、公式のSPIFFS github リポジトリでも報告されています。この問題は、 SPIFFS 構成によって部分的に軽減できます。
６．ガベージ コレクターがファイルシステム全体を複数回 (通常はデフォルトで 10 回) スキャンしてスペースを再利用しようとすると、各スキャン中に、ガベージ コレクターは使用可能なブロックがあれば 1 つを解放します。したがって、ガベージ コレクターに設定されている実行の最大数が ‘n’ ( SPIFFS 構成にある SPIFFS_GC_MAX_RUNS オプションで構成) の場合、ブロック サイズの n 倍がデータ書き込みに使用可能になります。ブロック サイズの n 倍を超えるデータを書き込もうとすると、書き込み操作が失敗し、エラーが返されることがあります。
７．ファイルシステムの操作中にチップの電源が失われると、SPIFFS が破損する可能性があります。ただし、関数によってファイルシステムを回復できる可能性がありますesp_spiffs_check。詳細については、公式の SPIFFS FAQを参照してください。
