feedc0de/esp-idf
1
0
Fork 0
forked from espressif/esp-idf
Code Pull Requests Activity

Merge branch 'docs/translate_file_system_consideration' into 'master'

Browse Source 
docs: Provide CN translation for file system considerations in IDF

Closes DOC-8963

See merge request espressif/esp-idf!33782
This commit is contained in:
Zhang Xiao Yan
2024-11-14 14:02:49 +08:00
parent d5f244c5f7 d7bc953d66
commit 074b74c701
2 changed files with 242 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
docs/en/api-guides/file-system-considerations.rst
View File

@@ -1,11 +1,13 @@
File System Considerations
==========================
:link_to_translation:`zh_CN:[中文]`
This chapter is intended to help you decide which file system is most suitable for your application. It points out specific features and properties of the file systems supported by the ESP-IDF, which are important in typical use-cases rather than describing all the specifics or comparing implementation details. Technical details for each file system are available in their corresponding documentation.
Currently, the ESP-IDF framework supports three file systems. ESP-IDF provides convenient APIs to handle the mounting and dismounting of file systems in a unified way. File and directory access is implemented via C/POSIX standard file APIs, allowing all applications to use the same interface regardless of the specific underlying file system:
Currently, the ESP-IDF framework supports three file systems. ESP-IDF provides convenient APIs to handle the mounting and dismounting of file systems in a unified way. File and directory access is implemented via C/POSIX standard file APIs, allowing all applications to use the same interface regardless of the underlying file system:
- :ref:`FAT (FatFS implementation) <fatfs-fs-section>`
- :ref:`FatFS <fatfs-fs-section>`
- :ref:`SPIFFS <spiffs-fs-section>`
- :ref:`LittleFS <littlefs-fs-section>`
@@ -13,7 +15,7 @@ All of them are based on 3rd-party libraries connected to the ESP-IDF through va
ESP-IDF also provides the NVS Library API for simple data storage use cases, using keys to access associated values. While it is not a full-featured file system, it is a good choice for storing configuration data, calibration data, and similar information. For more details, see the :ref:`NVS Library <nvs-fs-section>` section.
The most significant properties and features of above-mentioned file systems are summarised in the following table:
The most significant properties and features of above-mentioned file systems are summarized in the following table:
.. list-table::
:widths: 20 40 40 40
@@ -36,11 +38,11 @@ The most significant properties and features of above-mentioned file systems are
* Well documented
* Thread safe
* - Storage units and limits
- * Clusters (1-128 sectors)
- * Clusters (1–128 sectors)
* Supported sector sizes: 512 B, 4096 B
* FAT12: cluster size 512 B - 8 kB, max 4085 clusters
* FAT16: cluster size 512 B - 64 kB, max 65525 clusters
* FAT32: cluster size 512 B - 32 kB, max 268435455 clusters
* FAT12: cluster size 512 B – 8 kB, max 4085 clusters
* FAT16: cluster size 512 B – 64 kB, max 65525 clusters
* FAT32: cluster size 512 B – 32 kB, max 268435455 clusters
- * Logical pages, logical blocks (consists of pages)
* Typical setup: page = 256 B, block = 64 kB
- * Blocks, metadata pairs
@@ -50,7 +52,7 @@ The most significant properties and features of above-mentioned file systems are
- Integrated
- Integrated
* - Minimum partition size
- * 8 sectors with wear levelling on (4 FATFS sectors + 4 WL sectors with WL sector size = 4096B)
- * 8 sectors with wear levelling on (4 FATFS sectors + 4 WL sectors with WL sector size = 4096 B)
* plus 4 sectors at least
* real number given by WL configuration (Safe, Perf)
- * 6 logical blocks
@@ -60,7 +62,7 @@ The most significant properties and features of above-mentioned file systems are
- * FAT12: approx. 32 MB with 8 kB clusters
* FAT16: approx. 4 GB with 64 kB clusters (theoretical)
* FAT32: approx. 8 TB with 32 kB clusters (theoretical)
- Absolute maximum not specified More than 1024 pages per block not recommended
- Absolute maximum not specified, more than 1024 pages per block not recommended
- Not specified, theoretically around 2 GB
* - Directory Support
- * Yes (max 65536 entries in a common FAT directory)
@@ -72,7 +74,7 @@ The most significant properties and features of above-mentioned file systems are
- Yes
* - Power failure protection
- No
- Partial (see the SPIFFS notes)
- Partial (see :ref:`spiffs-fs-section`)
- Yes (integrated)
* - Encryption support
- Yes
@@ -91,7 +93,8 @@ For file systems performance comparison using various configurations and paramet
.. _fatfs-fs-section:
FatFS
----------------------
---------
The most supported file system, recommended for common applications - file/directory operations, data storage, logging, etc. It provides automatic resolution of specific FAT system type and is widely compatible with PC or other platforms. FatFS supports partition encryption, read-only mode, optional wear-levelling for SPI Flash (SD cards use own built-in WL), equipped with auxiliary host side tools (generators and parsers, Python scripts). It supports SDMMC access. The biggest weakness is its low resilience against sudden power-off events. To mitigate such a scenario impact, the ESP-IDF FatFS default setup deploys 2 FAT table copies. This option can be disabled by setting :cpp:member:`esp_vfs_fat_mount_config_t::use_one_fat` flag (the 2-FAT processing is fully handled by the FatFS library). See also related examples.
**Related documents:**
@@ -104,8 +107,8 @@ The most supported file system, recommended for common applications - file/direc
**Examples:**
* :example:`storage/sd_card`: access the SD card which uses the FAT file system
* :example:`storage/fatfs/ext_flash`: access the external flash chip which uses the FAT file system
* :example:`storage/sd_card` demonstrates how to access the SD card that uses the FAT file system.
* :example:`storage/fatfs/ext_flash` demonstrates how to access the external flash that uses the FAT file system.
.. _spiffs-fs-section:
@@ -122,7 +125,7 @@ SPIFFS is a file system providing certain level of power-off safety (see repair-
**Examples:**
* :example:`storage/spiffs` demonstrates how to use SPIFFS.
* :example:`storage/spiffs` demonstrates how to use SPIFFS on {IDF_TARGET_NAME} chip.
.. _littlefs-fs-section:
@@ -130,9 +133,9 @@ SPIFFS is a file system providing certain level of power-off safety (see repair-
LittleFS
----------------------
LittleFS is a block based file system designed for microcontrollers and embedded devices. It provides a good level of power failure resilience, implements dynamic wear levelling and has very low RAM requirements, the system has configurable limits and integrated SD/MMC card support. It is a recommended choice for general type of application, the only disadvantage is the file system not being natively compatible with other platforms (unlike FAT).
LittleFS is a block based file system designed for microcontrollers and embedded devices. It provides a good level of power failure resilience, implements dynamic wear levelling, and has very low RAM requirements. The system also has configurable limits and integrated SD/MMC card support. It is a recommended choice for general type of application. The only disadvantage is the file system not being natively compatible with other platforms (unlike FatFS).
LittleFS is available as external component in the ESP Registry, see `LittleFS component page <https://components.espressif.com/components/joltwallet/littlefs>`_ for the details on including the file system into your project.
LittleFS is available as external component in the `ESP Component Registry <https://components.espressif.com/>`_. See `LittleFS component page <https://components.espressif.com/components/joltwallet/littlefs>`_ for the details on including the file system into your project.
**Related documents:**
@@ -143,7 +146,7 @@ LittleFS is available as external component in the ESP Registry, see `LittleFS c
**Examples:**
* :example:`storage/littlefs` demonstrates how to use LittleFS.
* :example:`storage/littlefs` demonstrates how to use LittleFS on {IDF_TARGET_NAME} chip.
.. _nvs-fs-section:
@@ -151,6 +154,7 @@ NVS Library
---------------
Non-volatile Storage (NVS) is useful for applications depending on handling numerous key-value pairs, for instance application system configuration. For convenience, the key space is divided into namespaces, each namespace is a separate storage area. Besides the basic data types up to the size of 64-bit integers, the NVS also supports zero terminated strings and blobs - binary data of arbitrary length.
Features include:
* Flash wear leveling by design.
@@ -171,9 +175,9 @@ Points to keep in mind when developing NVS related code:
**Related documents:**
- To learn more about the API and NVS library details, see the :doc:`NVS documentation page <../api-reference/storage/nvs_flash>`
- For mass production, you can use the :doc:`NVS Partition Generator Utility <../api-reference/storage/nvs_partition_gen>`
- For offline NVS partition analysis, you can use the :doc:`NVS Partition Parser Utility <../api-reference/storage/nvs_partition_parse>`
- To learn more about the API and NVS library details, see the :doc:`NVS documentation page <../api-reference/storage/nvs_flash>`.
- For mass production, you can use the :doc:`NVS Partition Generator Utility <../api-reference/storage/nvs_partition_gen>`.
- For offline NVS partition analysis, you can use the :doc:`NVS Partition Parser Utility <../api-reference/storage/nvs_partition_parse>`.
**Examples:**
@@ -191,19 +195,19 @@ Here are several recommendation for building reliable storage features into your
* Use C Standard Library file APIs (ISO or POSIX) wherever possible. This high-level interface guarantees you will not need to change much, if it comes for instance to switching to a different file system. All the ESP-IDF supported file systems work as underlying layer for C STDLIB calls, so the specific file system details are nearly transparent to the application code. The only parts unique to each single system are formatting, mounting and diagnostic/repair functions
* Keep the file system dependent code separated, use wrappers to allow minimum change updates
* Design reasonable structure of your application file storage:
* Distribute the load evenly, if possible. Use meaningful number of directories/subdirectories (for instance FAT12 can keep only 224 record in its root directory).
* Distribute the load evenly, if possible. Use meaningful number of directories/subdirectories (for instance FAT12 can keep only 224 records in its root directory).
* Avoid using too many files or too large files (though the latter usually causes less troubles than the former). Each file equals to a record in the system's internal "database", which can easily end up in the necessary overhead consuming more space than the data stored. Even worse case is exhausting the filesystem's resources and subsequent failure of the application - which can happen really quickly in embedded systems' environment.
* Be cautious about number of write or erase operations performed in SPI Flash memory (for example, each write in the FatFS involves full erase of the area to be written). NOR Flash devices typically survive 100.000+ erase cycles per sector, and their lifetime is extended by the Wear-Levelling mechanism (implemented as a standalone component in corresponding driver stack, transparent from the application's perspective). The Wear-Levelling algorithm rotates the Flash memory sectors all around given partition space, so it requires some disk space available for the virtual sector shuffle. If you create "well-tailored" partition with the minimum space needed and manage to fill it with your application data, the Wear Levelling becomes ineffective and your device would degrade quickly. Projects with Flash write frequency around 500ms are fully capable to destroy average ESP32 flash in few days time (real world example).
* Be cautious about number of write or erase operations performed in SPI Flash memory (for example, each write in the FatFS involves full erase of the area to be written). NOR Flash devices typically survive 100,000+ erase cycles per sector, and their lifetime is extended by the Wear-Levelling mechanism (implemented as a standalone component in corresponding driver stack, transparent from the application's perspective). The Wear-Levelling algorithm rotates the Flash memory sectors all around given partition space, so it requires some disk space available for the virtual sector shuffle. If you create "well-tailored" partition with the minimum space needed and manage to fill it with your application data, the Wear Levelling becomes ineffective and your device would degrade quickly. Projects with Flash write frequency around 500ms are fully capable to destroy average ESP32 flash in few days time (real world example).
* With the previous point given, consider using reasonably large partitions to ensure safe margins for your data. It is usually cheaper to invest into extra Flash space than to forcibly resolve troubles unexpectedly happening in the field.
* Think twice before deciding for specific file system - they are not 100% equal and each application has own strategy and requirements. For instance, the NVS is not suitable for storing a production data, as its design doesn't deal well with too many items being stored (recommended maximum for NVS partition size would be around 128kB).
* Think twice before deciding for specific file system - they are not 100% equal and each application has own strategy and requirements. For instance, the NVS is not suitable for storing a production data, as its design doesn't deal well with too many items being stored (recommended maximum for NVS partition size would be around 128 kB).
Encrypting partitions
---------------------
{IDF_TARGET_NAME} based chips provide several features to encrypt the contents of various partitions within chip's main SPI flash memory. All the necessary information can be found in chapters :doc:`Flash Encryption <../security/flash-encryption>` and :doc:`NVS Encryption <../api-reference/storage/nvs_encryption>`. Both variants use the AES family of algorithms, the Flash Encryption provides hardware-driven encryption scheme and is transparent from the software's perspective, whilst the NVS Encryption is a software feature implemented using mbedTLS component (though the mbedTLS can internally use the AES hardware accelerator, if available on given chip model). The latter requires the Flash Encryption enabled as the NVS Encryption needs a proprietary encrypted partition to hold its keys, and the NVS internal structure is not compatible with the Flash Encryption design. Therefore, both features come separate.
Given storage security scheme and the {IDF_TARGET_NAME} chips design result into a few implications which may not be fully obvious in the main documents:
Considering the storage security scheme and the design of {IDF_TARGET_NAME} chips, there are several implications that may not be fully obvious in the main documents:
* The Flash encryption applies only to the main SPI Flash memory, due to its cache module design (all the "transparent" encryption APIs run over this cache). This implies that external flash partitions cannot be encrypted using the native Flash Encryption means.
* External partition encryption can be deployed by implementing custom encrypt/decrypt code in appropriate driver APIs - either by implementing own SPI flash driver (see :example:`storage/custom_flash_driver`) or by customizing higher levels in the driver stack, for instance by providing own :ref:`FatFS disk IO layer <fatfs-diskio-layer>`.

214
docs/zh_CN/api-guides/file-system-considerations.rst
View File

@@ -1 +1,213 @@
.. include:: ../../en/api-guides/file-system-considerations.rst
文件系统注意事项
==================
:link_to_translation:`en:[English]`
本文档旨在推荐最适合你的应用程序的文件系统。主要介绍了 ESP-IDF 所支持的文件系统的特定功能和属性，这些功能属性对于典型用例而言十分重要。如需获取每种文件系统的详细信息，请参阅相应的文档。
目前，ESP-IDF 框架支持三种文件系统。ESP-IDF 还提供了 API，用于批量处理文件系统的挂载和卸载。通过 C/POSIX 标准文件 API 能实现文件和目录的访问，使所有应用程序都可以使用相同接口，不受底层文件系统的影响。
- :ref:`FatFS <fatfs-fs-section>`
- :ref:`SPIFFS <spiffs-fs-section>`
- :ref:`LittleFS <littlefs-fs-section>`
这三种文件系统都是基于已有的第三方库，对其进行封装和修改后集成到 ESP-IDF。
ESP-IDF 还提供了非易失性存储 (NVS) 库 API，适用于简单的数据存储需求，通过键访问关联的值。该库虽然本身不是一个功能齐全的文件系统，但便于存储配置信息、校准数据以及类似信息。更多详细信息，请参阅 :ref:`NVS 库 <nvs-fs-section>` 小节。
上述文件系统的重要属性和功能如下表所示：
.. list-table::
:widths: 20 40 40 40
:header-rows: 1
* -
- FatFS
- SPIFFS
- LittleFS
* - 功能
- * 实现 MS FAT12、FAT16、FAT32 文件系统格式，可选 exFAT 文件系统的不同实现方式
* 在大多数硬件平台上广泛兼容的通用文件系统
* 文档完善
* 线程安全
- * 专为嵌入式系统中的 NOR flash 设备研发，低 RAM 占用
* 达到静态磨损均衡
* 不再维护，且文档较少
* 线程安全
- * 具备故障安全性，具备自身磨损均衡功能，固定 RAM（与文件系统大小无关）
* 文档完善
* 线程安全
* - 存储单位与限制
- * 簇（1～128 扇区）
* 支持的扇区大小：512 B，4096 B
* FAT12：簇大小 512 B ～ 8 kB，最多 4085 个簇
* FAT16：簇大小 512 B ～ 64 kB，最多 65525 个簇
* FAT32：簇大小 512 B ～ 32 kB，最多 268435455 个簇
- * 逻辑页、由页组成的逻辑块
* 典型配置：页大小 = 256 B，块大小 = 64 kB
- * 块、元数据对
* 典型配置：块大小 = 4 kB
* - 磨损均衡
- 可选（用于 SPI flash）
- 集成
- 集成
* - 最小分区大小
- * 8 个扇区启用磨损均衡（4 个 FATFS 扇区 + 4 个磨损均衡扇区，磨损均衡扇区大小为 4096 B）：
* 最少再加 4 个扇区
* 实际大小由磨损均衡配置（安全、性能）决定
- * 6 个逻辑块
* 每块 8 个页
- 未指定，理论上 2 个块
* - 最大分区大小
- * FAT12：约 32 MB（8 kB 簇）
* FAT16：约 4 GB（64 kB 簇，理论值）
* FAT32：约 8 TB（32 kB 簇，理论值）
- 未指定绝对最大值，不推荐超过每块 1024 页
- 未指定，理论上约 2 GB
* - 目录支持
- * 是（普通 FAT 目录中最多 65536 个条目）
* 限制：
* FAT12：根目录最多 224 个文件
* FAT16：根目录最多 512 个文件
* FAT32：根目录只是另一个目录
- 否
- 是
* - 电源故障保护
- 否
- 部分（见 :ref:`spiffs-fs-section`）
- 是（集成）
* - 加密
- 是
- 否
- 是
* - 支持目标
- * SPI flash (NOR)
* SD 卡
- SPI flash (NOR)
- * SPI flash (NOR)
* SD 卡 (IDF >= v5.0)
如需比较使用不同配置和参数的文件系统性能，请参阅存储性能基准测试示例 :example:`storage/perf_benchmark` 获取详细信息。
.. _fatfs-fs-section:
FatFS
----------
FatFS 是最适用于常见应用的文件系统，如文件/目录访问、数据存储、日志记录等。它能够自动识别特定的 FAT 文件系统类型，可与 PC 及其他平台良好兼容。FatFS 支持分区加密、只读模式、可选的 SPI flash 磨损均衡（SD 卡使用其内置的磨损均衡），并配备辅助的主机工具：生成器和分析器、Python 脚本。它还支持 SDMMC 访问。较为显著的缺点是应对突然断电能力不足。为降低这方面的不稳定性，ESP-IDF 的 FatFS 默认设置部署了两个 FAT 表副本。可以通过设置 :cpp:member:`esp_vfs_fat_mount_config_t::use_one_fat` 标志来禁用此选项（2-FAT 相关操作完全由 FatFS 库处理）。有关更多信息，请参见相关示例。
**相关文档:**
- `FatFS 源站点 <http://elm-chan.org/fsw/ff/>`_
- 更多关于 `FAT 表大小限制 <https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Size_limits>`_
- :ref:`using-fatfs-with-vfs`
- :ref:`using-fatfs-with-vfs-and-sdcards`
- ESP-IDF FatFS 工具： :ref:`FatFS 分区生成器 <fatfs-partition-generator>` 和 :ref:`FatFS 分区分析器 <fatfs-partition-analyzer>`
**示例:**
* :example:`storage/sd_card` 演示了如何访问使用 FAT 文件系统的 SD 卡。
* :example:`storage/fatfs/ext_flash` 演示了如何访问使用 FAT 文件系统的外部 flash。
.. _spiffs-fs-section:
SPIFFS
------------
SPIFFS 文件系统提供了一定程度的断电安全性（参见重启后修复函数 :cpp:func:`esp_spiffs_check`），并具有内置磨损均衡机制。由于其垃圾回收机制，当专用分区使用超过大约 70% 时，文件系统性能可能会下降，且不支持目录。SPIFFS 适用于仅需管理少量（可能是大型）文件，并要求较高数据一致性的场景。通常，SPIFFS 比 FatFS 占用更少的 RAM 空间，并支持最大 128 MB 的 flash 芯片。需要注意的是，SPIFFS 已不再开发和维护，因此请仔细斟酌是否优先选择此文件系统。
**相关文档:**
* :doc:`SPIFFS 文件系统 <../api-reference/storage/spiffs>`
* :ref:`生成 SPIFFS 镜像的工具 <spiffs-generator>`
**示例:**
* :example:`storage/spiffs` 演示了如何在 {IDF_TARGET_NAME} 上使用 SPIFFS 文件系统。
.. _littlefs-fs-section:
LittleFS
----------------------
LittleFS 是一种基于块的文件系统，专为微控制器和嵌入式设备设计。它具有良好的断电恢复能力，可实现动态磨损均衡，并且 RAM 占用少。此外，其限制配置可调整，支持直接在 SD/MMC 卡上操作。此文件系统适用于通用的应用，唯一的缺点是文件系统与其他平台的兼容性较差（不如 FatFS 文件系统）。
LittleFS 可以作为外部组件从 `ESP Component Registry <https://components.espressif.com/>`_ 获取。详细信息请参阅 `LittleFS 组件介绍 <https://components.espressif.com/components/joltwallet/littlefs>`_，以了解如何将该文件系统应用到项目中。
**相关文档:**
* `LittleFS 项目主页（源码、文档） <https://github.com/littlefs-project/littlefs>`_
* `LittleFS 辅助工具和相关项目 <https://github.com/littlefs-project/littlefs?tab=readme-ov-file#related-projects>`_
* `ESP-IDF 的 LittleFS 移植版 <https://github.com/joltwallet/esp_littlefs>`_
* `ESP-IDF LittleFS 组件 <https://components.espressif.com/components/joltwallet/littlefs>`_
**示例:**
* :example:`storage/littlefs` 演示了如何在 {IDF_TARGET_NAME} 上使用 LittleFS 文件系统。
.. _nvs-fs-section:
NVS 库
----------
非易失性存储（NVS）适用于需要处理大量键值对的应用场景，如应用系统配置。为了方便使用，键空间被划分为多个命名空间，每个命名空间是一个独立的存储区域。除了支持基本的数据类型（最大支持 64 位整数），NVS 还支持零终止字符串和长度可变的二进制大对象数据 (blob)。
NVS 具有如下特性：
* 支持 flash 磨损均衡。
* 突然断电保护（数据以确保原子更新的方式存储）。
* 支持加密（AES-XTS）。
* 提供设备生产过程和离线分析需要的数据准备工具。
在开发与 NVS 相关的代码时需要注意以下事项：
* 推荐的使用场景：用于存储不经常更改的配置数据。
* NVS 不适用于日志记录或其他需要频繁大量数据更新的场景，而适用于小规模的更新和低频率的写入。另一个限制是 flash 页面擦除的最大次数，对于 NOR flash 设备，通常为 100,000 左右。
* 如果需存储的数据组更新速率差异较大，建议为每个数据组创建不同的 NVS flash 分区，便于管理磨损均衡，降低数据损坏的风险。
* 默认的 NVS 分区（标记为 "nvs"）由其他 ESP-IDF 组件（如 Wi-Fi、蓝牙等）使用。为避免与其他组件发生冲突，建议为相关数据创建单独的分区。
* NVS 存储在 flash 中的分配单位是一个页面，即 4,096 字节。每个 NVS 分区至少需要三个页面才能正常工作。一个页面始终被保留，不用于数据存储。
* 在写入或更新现有数据之前，必须在 NVS 分区中有足够的空闲空间来存储旧数据和新数据。NVS 库不支持部分更新，因此跨 flash 页的大型 blob 数据可能需要更长的写入时间和更多的空间占用，增加实际操作的复杂性。
* NVS 库无法在不符合规格的电源环境中确保一致性，例如使用电池或太阳能面板供电的系统。在这种情况下，flash 数据的错误解析可能会导致 NVS flash 分区损坏。开发者应提供数据恢复代码，例如，基于具有工厂设置的只读数据分区。
* 已初始化的 NVS 库会占用 RAM 空间，这个占用量随着 flash 分区和缓存的键数量的增加线性增长。
**相关文档:**
- 有关 API 和 NVS 库的更多信息，请参阅 :doc:`非易失性存储库 <../api-reference/storage/nvs_flash>`。
- 有关批量生产的信息，请参阅 :doc:`NVS 分区生成程序 <../api-reference/storage/nvs_partition_gen>`。
- 有关离线 NVS 分区解析的信息，请参阅 :doc:`NVS 分区解析程序 <../api-reference/storage/nvs_partition_parse>`。
**示例:**
- :example:`storage/nvs_rw_value` 演示了如何写入和读取一个整数值。
- :example:`storage/nvs_rw_blob` 演示如何写入和读取一个 blob。
- :example:`security/nvs_encryption_hmac` 演示了如何用 HMAC 外设进行 NVS 加密，并通过 efuse 中的 HMAC 密钥生成加密密钥。
- :example:`security/flash_encryption` 演示了如何进行 flash 加密，包括创建和使用 NVS 分区。
文件处理设计注意事项
----------------------
关于将可靠的存储功能集成到应用程序中，建议如下：
* 尽可能使用 C 标准库文件 API（ISO 或 POSIX）。这种高级接口可以保证在切换到其他文件系统时，无需进行太多更改。ESP-IDF 支持的所有文件系统作为底层实现，供 C 标准库调用，开发代码无需了解文件系统的实现细节。每个系统唯一特有的部分是格式化、挂载以及诊断/修复功能。
* 将文件系统相关的代码分离并封装，尽量简化后续的更新。
* 采用合理的应用程序文件存储结构：
* 尽可能均匀分布负载。使用适当数量的目录/子目录（例如，FAT12 的根目录只能存储 224 条记录）。
* 避免使用过多、过大的文件（相对而言，文件数量过多更易引发问题）。每个文件相当于系统内部“数据库”中的一条记录，随着文件数量增加，管理这些文件所需的开销可能会超过实际存储的数据量。这会快速消耗文件系统资源，导致应用程序启动失败，这在嵌入式系统中尤为常见。
* 格外注意 SPI Flash 内存中执行的写入或擦除操作的次数（例如，在 FatFS 中每次写入都需要擦除全部的写入区域）。NOR flash 设备每个扇区通常可以承受超过 100,000 次擦除循环，磨损均衡机制延长了设备寿命。磨损均衡机制作为独立组件在相应的驱动程序堆栈中实现，对应用程序来说是透明的。由于磨损均衡算法会在给定的分区空间中轮换 flash 内存扇区，所以需要一些可用的磁盘空间进行虚拟扇区的调整。假设创建了一个“精确”划分的分区，被应用数据完全占用，磨损均衡机制就不再作用，造成设备快速老化。在实际应用中，flash 写入频率为 500 毫秒的项目，能够在几天内毁坏 ESP32 flash（真实案例）。
* 基于上述考虑，建议使用适当的较大分区，以确保数据的安全裕度。通常，预留额外的 flash 空间产生的成本要比被迫解决突发故障的成本更低。
* 根据应用程序实际所需，谨慎选择文件系统。例如，NVS 不建议用于存储生产数据，因为它不适合存储过多的项目（NVS 分区推荐最大容量大约为 128 kB）。
分区加密
------------
{IDF_TARGET_NAME} 芯片具有多种特性，支持加密芯片主 SPI Flash 内存中各分区内容。相关信息请参阅 :doc:`flash 加密 <../security/flash-encryption>` 和 :doc:`NVS 加密 <../api-reference/storage/nvs_encryption>`。这两种加密方式都使用 AES 算法，flash 加密提供硬件驱动的加密方案，对软件层完全透明；而 NVS 加密是基于 mbedTLS 组件实现的软件功能（如果芯片型号支持，mbedTLS 可以内部使用 AES 硬件加速器）。需注意，NVS 加密需启用 flash 加密，因为 NVS 加密需要一个专有的加密分区来存储密钥。然而 NVS 的内部结构与 flash 加密设计不兼容，二者实际是互相独立的。
鉴于存储安全方案和 {IDF_TARGET_NAME} 芯片设计，主要文档中可能并未明确以下两点：
* flash 加密仅适用于主 SPI flash 存储。这是因为它具有一个缓存模块，所有的透明加密 API 都通过该缓存模块进行。外部 flash 分区没有此缓存支持，所以无法利用原生 flash 加密功能来加密外部 flash 分区。
* 采取以下方式部署外部分区加密：实现自定义 SPI flash 驱动（参见 :example:`storage/custom_flash_driver`），或自定义驱动栈中的更高层，例如提供自定义的 :ref:`FatFS 磁盘 I/O 层 <fatfs-diskio-layer>`。