Nand flash文件系统总结 - 图文

NAND flash文件系统

目前flash的文件系统比较多，用的比较多的就是JFFS2文件系统。基于NOR flash上的JFFS2文件系统可以说算是比较成熟了，支持NAND flash的JFFS2也已经发布了。源代码可以到http://www.linux-mtd.infradead.org上面下载。但是在我的测试过程中，在nand flash上挂接的JFFS2文件系统很不稳定，经常有CRC错误产生。特别是进行写操作的时候，每次复位都会产生CRC错误，可以说支持NAND flash的JFFS2文件系统目前还不成熟。而YAFFS文件系统则是专门针对NAND flash的，源代码可以到

http://www.aleph1.co.uk/yaffs/index.html上下载。在测试过程中稳定性能比JFFS2文件系统要稳定的多，而且mount分区的时间也比JFFS2文件系统少的多。用JFFS2 mount一个2m的文件系统大约需要1s。下面分别介绍在uclinux下面使用JFFS2和YAFFS文件系统。 1、JFFS2

到http://www.linux-mtd.infradead.org上面下载最新的MTD和JFFS2压缩包。压缩包里面还有有关的内核补丁和一些MTD的相关工具。主要的补丁就是ilookup-2.4.23.patch，因为最新的MTD驱动中要用到一个ilookup（）函数。打完补丁、更新了MTD驱动和JFFS2文件系统之后就开始写自己nand flash驱动了。如果不想把JFFS2作为根文件系统的话，还需要修改MTD_BLOCK_MAJOR。驱动可以参考里面的例子，最简单的就是参考spia.c。

写驱动主要工作是定义flash分区结构、定义flash读写地址、写控制flash的**_hwcontrol()函数。具体的操作要看所用的nand flash的芯片资料。相对NOR flash来说驱动要简单多了。:) 改完之后再配置

Memory Technology Devices(MTD)下 CONFIG_MTD=Y

CONFIG_MTD_DEBUG=Y

CONFIG_MTD_DEBUG_VERBOSE=3 CONFIG_MTD_PARTITIONS=Y CONFIG_MTD_CHAR=Y CONFIG_MTD_BLOCK=Y

NAND Flash Device Drivers下 CONFIG_MTD_NAND=Y 定义自己的驱动文件 File systems下 CONFIG_JFFS2_FS=Y

CONFIG_JFFS2_FS_DEBUG=2

CONFIG_JFFS2_FS_NAND=y /*这个是新加的*/ 在uClinux v1.3.4 Configuration下 Flash Tools下

CONFIG_USER_MTDUTILS=Y

CONFIG_USER_MTDUTILS_ERASE=Y CONFIG_USER_MTDUTILS_ERASEALL=Y CONFIG_USER_MTDUTILS_MKFSJFFS2=Y

最后就是辛苦了调试工作了。:(MTD驱动调试完之后，就可以在上面挂接JFFS2文件系统了。参看flash分区情况：cat /proc/mtd，擦除分区:eraseall /dev/mtd*.例如把第一个分区mount到/mnt目录下面： 先:eraseall /dev/mtd0

然后:mount -t jffs2 /dev/mtdblock0 /mnt 2、YAFFS

YAFFS意义为'yet another flash file system'，也是一个开源的文件系统。YAFFS是目前为止唯一一个专门为NAND flash设计的文件系统，具有很好的可移植性，能够在linux，uclinux，和wince 下面运行。

在http://www.aleph1.co.uk/yaffs/index.html上下载源代码。压缩包里面也包含YAFFS的说明文档。YAFFS文件系统的源文件就devextras.h，yaffs_ecc.c，yaffs_ecc.h,yaffs_guts.c,yaffs_guts.h,yaffs_mtdif.h,yaffs_mtdif.c和yportenv.h

另外需要配置的宏：CONFIG_YAFFS_FS 和CONFIG_YAFFS_MTD_ENABLED，就是配置在mtd上面挂接YAFFS，其它还有一些辅助配置需要时也可以配置。 在fs目录下面建一个yaffs目录，把以上说的文件考里面去，新建一个makefile： O_TARGET := yaffs.o

obj-y := yaffs_fs.o yaffs_guts.o yaffs_mtdif.o yaffs_ecc.o obj-m := $(O_TARGET)

include $(TOPDIR)/Rules.make

接下来就是改fs目录下面config.in和makefile，在配置YAFFS的时候，把YAFFS连接进去。

如果像前面一样已经把NAND MTD驱动调好了，加YAFFS就很简单了。因为YAFFS是自己做ECC校验的，所以要把MTD驱动里面的ECC去掉。在驱动里面改成this->eccmode = NAND_ECC_NONE就可以了。

另外YAFFS是用mkyaffs来擦除flash，所以在mtd-utils中加上mkyaffs.c，一起编译进去。

最后就是编译了，呵呵。中间会有一些警告没有关系的，就是写没有用的变量和函数，不过话说回来YAFFS的代码写的确实不太规范。当然它的性能确实没话说。有兴趣的可以试一下-。

1. JFFS2文件系统

JFFS2是JFFS的后继者，由Red Hat重新改写而成。JFFS2的全名为Journalling Flash File System Version 2（闪存日志型文件系统第2版），其功能就是管理在MTD设备上实现的日志型文件系统。与其他的存储设备存储方案相比，JFFS2并不准备提供让传统文件系统也可以使用此类设备的转换层。它只会直接在MTD设备上实现日志结构的文件系统。JFFS2会在安装的时候，扫描MTD设备的日志内容，并在RAM中重新建立文件系统结构本身。

除了提供具有断电可靠性的日志结构文件系统，JFFS2还会在它管理的MTD设备上实现“损耗平衡”和“数据压缩”等特性。

节点头部定义和兼容性

JFFS2 将文件系统的数据和原数据以节点的形式存储在闪存上，具体来说节点头部的定义如下： 图一 幻数屏蔽位：0x1985 用来标识 JFFS2 文件系统。 节点类型：JFFS2 自身定义了三种节点类型，但是考虑到文件系统可扩展性和兼容性，JFFS2从 ext2 借鉴了经验，节点类型的最高两位被用来定义节点的兼容属性，具体来说有下面几种兼容属性： JFFS2_FEATURE_INCOMPAT：当 JFFS2 发现了一个不能识别的节点类型，并且它的兼容属性是 JFFS2_FEATURE_INCOMPAT，那么 JFFS2 必须拒绝挂载(mount)文件系统。 JFFS2_FEATURE_ROCOMPAT：当 JFFS2 发现了一个不能识别的节点类型，并且它的兼容属性是 JFFS2_FEATURE_ROCOMPAT，那么 JFFS2 必须以只读的方式挂载文件系统。 JFFS2_FEATURE_RWCOMPAT_DELETE：当 JFFS2 发现了一个不能识别的节点类型，并且它的兼容属性是 JFFS2_FEATURE_RWCOMPAT_DELETE，那么在垃圾回收的时候，这个节点可以被删除。 JFFS2_FEATURE_RWCOMPAT_COPY：当 JFFS2 发现了一个不能识别的节点类型，并且它的兼容属性是 JFFS2_FEATURE_RWCOMPAT_COPY，那么在垃圾回收的时候，这个节点要被拷贝到新的位置。 节点总长度：包括节点头和数据的长度。 节点头部 CRC 校验：包含节点头部的校验码，为文件系统的可靠性提供了支持。

节点类型 JFFS2 定义了三种节点类型： JFFS2_NODETYPE_INODE： INODE 节点包含了i-节点的原数据(i节点号，文件的组 ID, 属主 id, 访问时间，偏移，长度等)，文件数据被附在 INODE 节点之后。除此之外，每个 INODE 节点还有一个版本号，它被用来维护属于一个i-节点的所有 INODE 节点的全序关系。下面举例来说明这个全序关系在 JFFS2 的使用： 图二 因此，当文件系统从闪存上读节点信息后，会生成下面的映射信息： 图三

根据这个映射信息表，文件系统就知道到相应的 INODE 节点去读取相应的文件内容。 最后要说明的是，JFFS2 支持文件数据的压缩存储，因此在 INODE 节点中还包含了所使用的压缩算法，在读取数据的时候选择相应的压缩算法来解压缩。

JFFS2_NODETYPE_DIRENT：DIRENT 节点就是把文件名与 i 节点对应起来。在 DIRENT节点中也有一个版本号，这个版本号的作用主要是用来删除一个 dentry。具体来说，当我们要从一个目录中删除一个 dentry 时，我们要写一个 DIRENT 节点，节点中的文件名与被删除的 dentry 中的文件名相同，i 节点号置为 0，同时设置一个更高的版本号。

JFFS2_NODETYPE_CLEANMARKER：当一个擦写块被擦写完毕后，CLEANMARKER 节点会被写在 NOR flash 的开头，或 NAND flash 的 OOB(Out-Of-Band) 区域来表明这是一个干净，可写的擦写块。在 JFFS v1 中，如果扫描到开头的 1K 都是 0xFF 就认为这个擦写块是干净的。但是在实际的测试中发现，如果在擦写的过程中突然掉电，擦写块上也可能会有大块连续 0xFF，但是这并不表明这个擦写块是干净的。于是我们需要 CLEANMARKER 节点来确切的标识一个干净的擦写块。

JFFS2节点，擦写块在内存中的表示和操作

JFFS2 维护了几个链表来管理擦写块，根据擦写块上的内容，一个擦写块会在不同的链表上。具体来说，当一个擦写块上都是合法(valid)的节点时，它会在 clean_list 上；当一个擦写块包含至少一个过时(obsolete)的节点时，它会在 dirty_list 上；当一个擦写块被擦写完毕，并被写入 CLEANMARKER 节点后，它会在 free_list 上。

通常情况下，JFFS2 顺序的在擦写块上写入不同的节点，直到一个擦写块被写满。此时 JFFS2 从 free_list 上取下一个擦写块，继续从擦写块的开头开始写入节点。当 free_list 上擦写块的数量逐渐减少到一个预先设定的阀值的时候，垃圾回收就被触发了，为文件系统清理出更多的可用擦写块。 为了减少对内存的占用，JFFS2 并没有把 i 节点所有的信息都保留在内存中，而只是把那些在请求到来时不能很快获得的信息保留在内存中。具体来说，对于在闪存上的每个 i 节点，在内存里都有一个 struct jffs2_inode_cache 与之对应，这个结构里保存了 i 节点号，指向 i 节点的连接数，以及一个指向属于这个 i 节点的物理节点链表的指针。所有的 struct jffs2_inode_cache 存储在一个哈希表中。闪存上的每个节点在内存中由一个 struct jffs2_raw_node_ref 表示，这个结构里保存了此节点的物理偏移，总长度，以及两个指向 struct jffs2_raw_node_ref 的指针。一个指针指向此节点在物理擦写块上的下一个节点，另一个指针指向属于同一个 i-节点的物理节点链表的下一个节点。 图四

在闪存上的节点的起始偏移都是 4 字节对齐的，所以 struct jffs2_inode_cache 中

flash_offset 的最低两位没有被用到。JFFS2 正好利用最低位作为此节点是否过时的标记。

下面举一例来说明 JFFS2 是如何使用这些数据结构的。VFS 调用 iget() 来得到一个 i 节点的信息，当这个 i 节点不在缓存中的时候，VFS 就会调用 JFFS2 的 read_inode() 回调函数来得到 i 节点信息。传给 read_inode() 的参数是 i 节点号，JFFS2 用这个 i 节点号从哈希表中查找相应的 struct jffs2_inode_cache，然后利用属于这个 i 节点的节点链表从闪存上读入节点信息，建立类似于表三的映射信息。

JFFS2 挂载过程

JFFS2 的挂载过程分为四个阶段：

1) JFFS2 扫描闪存介质，检查每个节点 CRC 校验码的合法性，同时分配了 struct jffs2_inode_cache 和 struct jffs2_raw_node_ref

2) 扫描每个 i 节点的物理节点链表，标识出过时的物理节点；对每一个合法的 dentry 节点，将相应的 jffs2_inode_cache 中的 nlink 加一。 3 找出 nlink 为 0 的 jffs2_inode_cache，释放相应的节点。 4 释放在扫描过程中使用的临时信息。

JFFS2 垃圾回收机制

当 free_list 上的擦写块数太少了，垃圾回收就会被触发。垃圾回收主要的任务就是回收那些已经过时的节点，但是除此之外它还要考虑磨损平衡的问题。因为如果一味的从 dirty_list上选取擦写块进行垃圾回收，那么 dirty_list 上的擦写块将先于 clean_list 上的擦写块被磨损坏。JFFS2 的处理方式是以 99% 的概率从 dirty_list，1% 的概率从 clean_list 上取一个擦写块下来。由此可以看出 JFFS2 的设计思想是偏向于性能，同时兼顾磨损平衡。对这个块上每一个没有过时的节点执行相同的操作： 1 找出这个节点所属的 i 节点号(见图五)。

2 调用 iget()，建立这个 i 节点的文件映射表。

3 找出这个节点上没有过时的数据内容，并且如果合法的数据太少，JFFS2 还会合并相邻的节点。

4 将数据读入倒缓存里，然后将它拷贝到新的擦写块上。 5 将回收的节点置为过时。

当擦写块上所有的节点都被置为过时，就可以擦写这个擦写块，回收使用它。

挂载时间过长

JFFS2 的挂载过程需要对闪存从头到尾的扫描，这个过程是很慢的，我们在测试中

发现，挂载一个 16M 的闪存有时需要半分钟以上的时间。

磨损平衡的随意性(random nature)

JFFS2 对磨损平衡是用概率的方法来解决的，这很难保证磨损平衡的确定性。在某些情况下，可能造成对擦写块不必要的擦写操作；在某些情况下，又会引起对磨损平衡调整的不及时。

很差的扩展性

JFFS2 中有两个地方的处理是 O(N) 的，这使得它的扩展性很差。

首先，挂载时间同闪存的大小，闪存上节点数目成正比。

其次，虽然 JFFS2 尽可能的减少内存的占用，但通过上面对 JFFS2 的介绍我们可以知道实际上它对内存的占用量是同 i 节点数和闪存上的节点数成正比的。 因此在实际应用中，JFFS2 最大能用在 128M 的闪存上。

JFFS2 的新特性

最近加入到 JFFS2 中的两个补丁程序分别解决了上面提到的挂载时间过长和磨损平衡随意性的问题。

磨损块小结补丁程序

这个补丁程序最基本的思想就是用空间来换时间。具体来说，就是将每个擦写块每个节点的原数据信息写在这个擦写块的最后，当 JFFS2 挂载的时候，对每个擦写块只需要读一次来读取这个小结节点，因此大大减少了挂载时间。使用了磨损块小结补丁程序，一个擦写块的结构就像下面这样： 图五

根据我们的测试，使用磨损块小结补丁程序，挂载一个 12M 的闪存需要 2~3 秒，挂载一个 16M 的闪存需要 3~4 秒。

改进的磨损平衡补丁程序

这个补丁程序的基本思想是，记录每个擦写块的擦写次数，当闪存上各个擦写块的擦写次数的差距超过某个预定的阀值，开始进行磨损平衡的调整。调整的策略是，在垃圾回收时将擦写次数小的擦写块上的数据迁移到擦写次数大的擦写块上。这样一来我们提高了磨损平衡的确定性，我们可以知道什么时候开始磨损平衡的调整，也可以知道选取哪些擦写块进行磨损平衡的调整。

擦写块头部补丁程序

在写改进的磨损平衡补丁程序的过程之中，我们需要记录每个擦写块的擦写次数，这个信息需要记录在各自的擦写块上。可是我们发现 JFFS2 中缺少一种灵活的对每个擦写块的信息进行扩展的机制。于是我们为每个擦写块引入了擦写块头部(header)，这个头部负责纪录每个擦写块的信息(比如说擦写次数)，并且它提供了灵活的扩展机制，将来如果有新的信息需要记录，可以很容易的加入到头部之中。[1] 2.YAFFS文件系统简介 YAFFS（Yet Another Flash File System）是第一个专门为NAND Flash存储器设计的嵌入式文件系统，适用于大容量的存储设备；并且是在GPL（General Public License）协议下发布的，可在其网站免费获得源代码。

YAFFS 是基于日志的文件系统，提供磨损平衡和掉电恢复的健壮性。它还为大容量的Flash 芯片做了很好的调整，针对启动时间和RAM 的使用做了优化。它适用于大容量的存储设备，已经在Linux 和WinCE 商业产品中使用。 YAFFS中，文件是以固定大小的数据块进行存储的，块的大小可以是512字节、1 024字节或者2 048字节。这种实现依赖于它能够将一个数据块头和每个数据块关联起来。每个文件（包括目录）都有一个数据块头与之相对应，数据块头中保存了ECC(Error Correction Code)和文件系统的组织信息，用于错误检测和坏块处理。充分考虑了NAND Flash的特点，YAFFS把这个数据块头存储在Flash的16字节备用空间中。当文件系统被挂载时，只须扫描存储器的备用空间就能将文件系统信息读入内存，并且驻留在内存中，不仅加快了文件系统的加载速度，也提高了文件的访问速度，但是增加了内存的消耗。

为了在节省内存的同时提高文件数据块的查找速度，YAFFS利用更高效的映射结构把文件位置映射到物理位置。文件的数据段被组织成树型结构，这个树型结构具有32字节的节点，每个内部节点都包括8个指向其他节点的指针，叶节点包括16个2字节的指向物理地址的指针。YAFFS在文件进行改写时总是先写入新的数据块，然后将旧的数据块从文件中删除。这样即使在修改文件时意外掉电，丢失的也只是这一次修改数据的最小写入单位，从而实现了掉电保护，保证了数据完整性。 结合贪心算法的高效性和随机选择的平均性，YAFFS实现了兼顾损耗平均和减小系统开销的目的。当满足特定的小概率条件时，就会尝试随机选择一个可回收的页面；而在其他情况下，则使用贪心算法来回收最“脏”的块[2]。

原理简介

YAFFS文件系统是按层次结构设计的，分成以下4部分： yaffs_guts.c，文件系统

的主要算法，这部分代码完全是用可移植的C语言编写的；yaffs_fs.c，Linux VFS层的接口；NAND 接口，yaffs_guts 和NAND 内存访问函数之间的包装层，例如调用Linux mtd 层或者RAM模拟层；可移植函数，服务的包装函数。最重要的一点是，为了获得更好的移植性，YAFFS提供直接调用的模式，这才使得我们有机会来实现YAFFS文件系统在C51系统上的移植。

3.SFFS Flash File System

Summary

SFFS is a Safe Flash File System that can support almost any NOR or NAND flash device. It provides a high degree of reliability and complete protection against unexpected power failure or reset events. SFFS provides wear leveling, bad block handling and ECC algorithms to ensure you get optimal use out of a flash device. SFFS is pre-integrated with the MQX RTOS and allows you to quickly create a a robust file system for an embedded device using on-chip or on-board flash devices.

Key Features

Designed for Embedded| NAND / NOR Support | Reliability & Integrity | High Performance | Maximum Use of Flash | Optimized for ColdFire and Power Architecture | Licensing | Compatible Products

Designed for Embedded Applications

The SFFS Flash File System was specifically designed for embedded systems. Taking into account the limited memory and real-time response requirement of many embedded applications, SFFS allows embedded software developers to implement a full featured file system that uses flash devices as a storage medium. This means that embedded applications can read and store data into non-volatile and inexpensive flash memory instead of requiring a hard disk drive or other mechanical media. A key requirement of a rugged flash file system is the ability to maintain the file system integrity across unexpected power loss or resets that are common in many embedded devices. SFFS is designed to ensure that the software never risks corrupting the file system or losing stored data.

The SFFS Flash File System has been tested on embedded microprocessor architectures such as Freescale’s ColdFire and Power Architecture architectures. Flash device drivers for flash components commonly used with ColdFire and Power Architecture chips have been integrated with the SFFS file system. Integration with Freescale’s CodeWarrior tools ensures a great out-of-box experience for SFFS developers using these processor architectures. SFFS has ben pre-integrated with the MQX RTOS but can also be used with any real-time operating system.

SFFS provides the key features that you would expect from a desktop PC file system such as support for long file names, multiple disk volumes, and directory handling. It also allows multiple files to be open simulatenously and provides a standard API.

Supports NOR or NAND Flash

The SFFS Flash File System is designed to support both NOR and NAND flash devices.

NOR Flash

NOR flash is one of the building blocks of most embedded systems. It provides non-volatile storage of data and code for systems. It is characterized by having storage that can only be written to if previously erased and erasable blocks with relatively long erase times.

There are literally thousands of NOR flash devices available all with slightly different characteristics while retaining the same base properties. The SFFS Flash file system supports most major manufacturer's devices including:

? ? ? ? ? ?

AMD/Fujitsu/Spansion flash chips including MirrorBit technology Intel StrataFlash

Atmel devices including the small memory devices Sharp Flash Memory

SST including 25 and 39 series Toshiba Flash Memory

NAND Flash

NAND flash is a relatively new flash technology designed to store large amounts of non-volatile data at reduced cost. It is characterized by having storage that can only be written to if previously erased - these blocks erase quicker than on NOR flash but is still quite long. Other features that differentiate it from NOR flash are that it is often shipped with a number of bad-blocks and their reliability is much increased if all single bit errors are detected and fixed.

There are many different NAND flash devices available all with slightly different characteristics while retaining the same base properties. The SFFS Flash file system supports NAND devices from most major manufacturers including devices from::

? ? ? ? ?

Samsung Hitachi Toshiba Micron ST Micro

Provides Reliability and Integrity

Embedded devices do not have the luxury of sophisticated disk recovery programs as PC compatible devices do. If an embedded device file system gets corrupted because an erase or write operation is unexpectedly terminated the result could be lost sectors or a loss of the whole device. A robust flash file system must be designed to restore itself from any situation or system failure.

To achieve this a complete new file system must be available for use before any information is erased. In this way, if the worst happens the system can be rebuilt either in its pre-write form or with the new modifications included. This is not possible to guarantee with a DOS compatible file system and with many other file systems. Efficient implementation of this methodology with flash devices, which require sectors to be erased before writing is complex. Write and erase times can be relatively long on flash devices and it is extremely important to ensure the number of these operations is minimized. The write/erase performance of SFFS is highly optimized to ensure a high-level of performance for a 100% power-file safe system.

In order to verify the reliability of the SFFS Flash File System and ensure that data integrity is always guaranteed extenisve verification is done using thousands of PC simulations of NOR and NAND flash devices and with real-world testing on actual NOR and NAND flash arrays.

High Performance Operation

Flash devices have special characteristics - in particular their write and erase times may be comparatively long. SFFS is a highly crafted flash file system designed to make the most efficient use of the underlying flash devices. It does not use a flash translation layer - instead it works directly with its knowledge of the devices to give an efficient solution. In particular a sophisticated write caching system has been developed in which only changes to the file descriptor tables are stored in flash. This allows many updates to be performed with an absolute minimum of flash chip usage while always maintaining the 100% power-fail resilience of the system.

Algorithms are also provided to support the use of Erase Suspend/Resume so that blocks that are known to be erasable are erased by an interruptible thread. Additonally logic is included to select pre-erased blocks preferentially while still maintaining efficient wear algorithms. There are many algorithms employed to execute as efficiently as possible without over using the flash - these are done because the file system has direct knowledge of the erase/write structure of the attached devices.

Maximizes Use of Flash

Flash devices ultimately have limited life spans. Typically manufactures specify a maximum number of write/erase cycles for a device after which failures can be expected. A robust flash file system needs to be able to take this into account to ensure that it maximizes the use of a particular flash component. In addition, embedded devices can have unique requirements in terms of using parts of the the flash for other purposes

other than the file system or unique configurations of multiple flash chips in arrays designed to achieve higher performance than a single chip. The SFFS flash file system is designed to maximize the use of the available flash and is flexible enought to use

any

flash

configuration.

Wear-leveling

Flash devices suffer from over-use - if a particular block is used beyond the manufacturer's

specification the block may eventually develop errors. To combat this eventuality, wear-level algorithms are implemented

in

SFFS

which ensure an even usage of the blocks. In addition the method of recording changes to the file descriptors ensures that the minimum of writing is done.

Bad-Block Management

Bad blocks may develop in a device over time. These are automatically detected by the SFFS file sytem and are paged out of the file system ensuring that they are never written to or erased.

Reserved Sectors

Developers often require that sections of their flash device are reserved for a particular purpose outside of the file system. This is achieved by specifying in the SFFS driver which of the available blocks are for \The user can still use the standard low-level read/write/erase routines for accessing these blocks.

Flash Arrays

In embedded hardware designs it is common to use multiple flash devices in a system either in parallel to widen the data bus and acheive higher performance, or in series to increase storage size. This behaviour is fully supported by the SFFS Flash File System and relies only on configuration changes to the drivers.

ECC Algoritms

For NAND flash deivces Error Checking & Correction (ECC) may be implemented either in hardware or software. A highly efficient ECC algorithm is provided with the SFFS file system for NAND flash devices. The algorithm automatically corrects all single bit errors, resulting in substantial increase in the relaibility of these flash devices.

Optimized for ColdFire and Power Architecture Processors

Embedded Access specializes in solutions for ColdFire and Power Architecture processors. Our engineers have been working with ColdFire and Power Architecture architectures since their launch and with the 68K architecture before that. This level of understanding for the ColdFire and Power Architecture processor architectures results in the SFFS Flash File System product being specifically

optimized and pre-integrated for these platforms. The SFFS file system includes flash device drivers for flash chips that commonly appear on Freescale ColdFire and Power Architecture development boards such as Intel Strata flash and devices from AMD and Atmel. This level of integration ensures a very good out-of-box experience with ColdFire and Power Architecture development boards and easy integration of the SFFS Flash File System with a customer's hardware.

Business-Friendly, Royalty-Free, Source Licensing Model

The SFFS Flash File System is licensed and delivered with full source code, so there are no mysteries about how the file system operates. The source code includes all of the flash device code so that users can quickly adapt it and reuse the provided code to port the file system to their own flash hardware.

The simple SFFS licensing terms ensures there are no legal ambiguities. The SFFS file system installation provides excellent source code without leaving you wondering about potential exposure to the open-source legal issues. Whatever our customers develop is theirs; their proprietary features and code can remain as private as they decide. What's more, the SFFS is licensed without royalties, so it offers a blend of the best of both the professional software world and the open-source world.

Compatible Products from Embedded Access

The following products enhance the MQX RTOS for more advanced applications:

? ? ? ? ? ?

MQX RTOS RTCS Embedded Internet Stack

EUSB Device Embedded USB Device Stack EUSB Host Embedded USB Host Stack PEG+ Graphics Library for MQX HTTP Web Servers 4．smxFFS

Flash File System

smxFFS is a flash file system for use with board-resident arrays of NAND and NOR flash

memory. It has the standard C library file API, it is power fail-safe, and it has a small

memory footprint. It has been completely redesigned in v2.

Overview

smxFFS is a simple, power fail-safe flash file system for NAND and NOR flash. It provides the standard C library API (fopen(), fread(), fwrite(), fseek(), fclose(), etc.) to the

application. Unlike the smxFS FAT file system, the smxFFS file structure is not DOS- or Windows-compatible. It was designed specifically for flash memory.

Large Flash / Small Footprint

smxFFS was designed to support very large flash devices, up to 256TB, yet have a small footprint (see Features).

Power-Fail-Safe Operation

Unlike the FAT file system, smxFFS has no FAT area, and each file’s metadata (like a directory entry in the FAT file system) is located in a separate sector, so if power fails during a file operation, only those files that are not closed may lose data. Other files and the file system itself will not be damaged. smxFFS has a built-in routine to check every file on the flash disk when mounting it to remove any unexpected data.

Porting Layer

Although integrated with the SMX? RTOS, smxFFS can be ported to other RTOSes or run standalone. The porting layer is based on smxBase. You also need to port smxNAND and smxNOR to your hardware platform.

Limitations

In order to achieve the small footprint yet large flash support, it was necessary to put some restrictions on the capabilities of smxFFS.

? ?

Maximum file length is 4GB-2.

Maximum file name length and number of files per directory is specified at compile time.

Subdirectories limited to 3 levels of nesting and 254 files per directory. Moderate performance. ? ? sff_init () sff_exit () sff_devreg (dev_if, id) sff_devunreg (id) Initialize the file system. Uninitialize the file system. Register a device driver to the system. Un-Register a device driver from the system. sff_fopen (filename, mode) Open a file for read/write access. sff_fclose (filehandle) Close an open file and flush all data to the storage media. sff_fread (buf, size, items, Read data from an open file. filehandle) sff_fwrite (buf, size, items, filehandle) sff_fseek (filehandle, offset, method) sff_fdelete (filename) sff_rename (oldname, newname) sff_timestamp (filename, datetime) Write data to an open file. Move the file pointer to the specified location. Delete a file. Rename a file or directory. Set a file’s modification timestamp. sff_filelength (filename) Return the length of a file, in bytes. sff_rewind (filehandle) sff_fflush (filehandle) sff_ftell (filehandle) Move the file pointer to the beginning of the file. Flush all data associated with the file handle to the storage media. Determine the current file pointer position. Test for end-of-file. Test if a file exists. Provide information about the first instance of a file whose name matches the name specified by the filespec argument. sff_truncate (filehandle) Truncate a file at the current file pointer. sff_feof (filehandle) sff_findfile (filename) sff_findfirst (filespec, fileinfo) Find the next file, if any, whose name matches the filespec argument in a previous sff_findnext (id, fileinfo) call to sfs_findfirst(), and return info about it in fileinfo structure. sff_findclose (fileinfo) sff_mkdir (path) sff_rmdir (path) sff_chkdsk (id) sff_format (id) sff_freekb (id) Clean up after the findfirst/findnext operation. Create a new directory. Remove a directory. Check and fix disk problems. Format the storage media. Return the number of free KB on the storage media. sff_totalkb (id) sff_clustersize (id) Size and Performance Code Size

Code size varies depending upon the CPU, compiler, and optimization level.

Return the number of total KB on the storage media. Return the data cluster size. CPU and Compiler ARM & IAR 6.10 Data Size

smxFFS (KB) 20 smxNAND (KB) 14 smxNOR (KB) 5 Data size only depends upon the flash sector size and number of open files. smxNAND data size increases with flash size. 13KB for 256MB flash disk; 37KB for 1GB flash disk. See the smxNAND datasheet for more size information. smxNOR data size is not affected by flash size.

Sector Size and Open Files 512 byte sector size, one open file 2048 byte sector size, one open file Performance smxFFS (KB) 4 10 smxNAND (KB) 13 13 smxNOR (KB) 1.5 1.5 Performance highly depends upon the flash chip, bus speed, microprocessor speed, and RAM speed. It is recommended that you do measurements on your hardware before making final design decisions, if performance is critical. The results here are intended only to provide guidance.

Sector Size and Open Files AT91SAM9M10G45-EK, 256MB NAND Reading (KB/s) 5600 Writing (KB/s) 1900 5.FAT over NAND Flash

需要在NAND FLASH裸片上建立文件系统，由于必须通过USB给Windows访问，所以FAT是唯一的选择。由于FAT不是为Flash设计，因此需要透过FTL（Flash Translation Layer）来访问NAND FLASH。

原本以为FTL的支持在嵌入式Linux下是很成熟的，因为在编译内核时，MTD下就有可选的FTL和NFTL可供选择，但是dig进去才发现原来事情比想象的复杂。 首先科普一下：

1） FLASH的擦除循环寿命比较有限。对于NOR FLASH大约100万次，对于NAND FLASH大约10万次（SLC）或几万次（MLC）。

2）NAND FLASH出厂时可能存在坏块，而且在使用中有可能不断地产生新的坏块。所谓“坏块”其实通常从仅有一个bit（SLC）或数个bits（MLC）出错开始。一般可以通过ECC，BCH或RS算法还原数据来大幅度提升NAND FLASH的寿命（10倍左右）。

3）可擦除块： FLASH与磁盘的一个重要区别，就是FLASH在写入之前必须先进行擦除。经过擦除后的FLASH，内容全部为‘1’。写入的过程就是把一些'1'的比特改成'0'。对于FLASH存储器，内容为'0'的比特数据需要擦除为‘1’后才能再次写入（变为'0'）。对于NAND FLASH还更复杂些，NAND FLASH的存储单位被组织成页，页的大小一般为512/1024/2048/4096字节，同一个页的写入次数有限制（称为'写入区'，‘写入区’的个数就是页写入的最大次数），通常为2次。FLASH的可擦除块一般在数十k到几百k。

4）FTL： FLASH传输层软件，有两个作用， 一是对FLASH写入进行负载均衡，由此提升FLASH的寿命；二是提供类似传统磁盘大小的块（512 bytes）访问界面，以便可以在FLASH上使用为磁盘存储介质而设计的文件系统，如FAT。 5）NFTL：适合NAND FLASH的FTL。与NOR FLASH相比，增加了坏块管理，页管理，以及ECC等纠错措施。

为什么要FTL？

由于传统的文件系统不是为Flash而设计的，如果直接在Flash上运行会很快使Flash局部老化而丢失数据，或崩溃。另外由于FLASH的块比较大，如果直接映射成块设备的话，空间利用率低。

FTL的作用就是解决负载均衡与提供适合传统文件系统的，大小合适（如512字节）的块设备。

MTD

很多刚接触Linux MTD系统的人，很容易把mtd和FTL搞混了。mtd设备是一个字符设备（或者叫\设备），它提供了访问FLASH存储器的通用界面。MTD还带了一个简单的模拟块设备：mtdblock。虽然mtdblock提供了大小合适的块，但它不具备负载均衡的能力，也不具备坏块管理的能力。我们可以通过mtdblock设备安装传统文件系统（如FAT文件系统），但是如果在上面进行写入操作的话，会迅速磨损FLASH。（如果安装的是一个只读文件系统，则没有问题）

许多Flash-aware-filesystem，如JFFS和YAFFS，通过mtd来访问FLASH；而要在FLASH上使用传统文件系统，一个可靠的FTL是一定需要的。

Linux下的FTL和NFTL

Linux内核的MTD子系统中带有FTL和NFTL，但它们实际上不是通用的FTL，有诸多的限制。更要命的是它的许可证：

写道

LEGAL NOTE: The FTL format is patented by M-Systems. They have granted a license for its use with PCMCIA devices:

\any presently existing M-Systems intellectual property rights necessary for the design and development of FTL-compatible

drivers, file systems and utilities using the data formats with PCMCIA PC Cards as described in the PCMCIA Flash Translation Layer (FTL) Specification.\

Use of the FTL format for non-PCMCIA applications may be an infringement of these patents. For additional information, contact M-Systems (http://www.m-sys.com) directly.

在嵌入式系统中，FLASH通常是直接与CPU通过内存总线通讯，而不是PCMCIA接口，因此这个许可证就使得通过非PCMCIA接口使用FTL有可能侵权。

也许是因为这个原因，FTL和NFTL代码中并不提供对非DiskOnChip(PCMCIA) 设备的支持。

UBI

UBI原本是为了实现更好的负载均衡（全片负载均衡）和更好的扩展性。UBI架构在MTD之上，它要完成的工作就是实现透明的负载均衡和坏块管理，让上层的文件系统从这两部分繁重的工作中释放出来。

看起来与FTL很接近了，只可惜它提供的不是我们需要的块设备。与MTD一样，它提供的界面是\设备，供flash-aware-filesystem使用。例如可以在UBI之上使用JFFS2（据说可以获得更好的负载均衡特性），或者专门设计的UBIFS。

UBI是由Nokia开发人员发起的项目，开发者声称基于UBI建立FTL很容易...容易到他们都不屑于去实现它了。我们悲哀地发现，虽然UBI项目已经有好几年了，也进入main stream内核了，却还看不到基于它的FTL。

其实并不是没有人需要FTL，在google上搜一下就会发现有大把的人在寻找在Linux下可用的FTL，最终得到的答案要么是“没有”，要么是“基于UBI很容易实现FTL”云云。

其实从技术上讲基于UBI实现FTL确实是省了很多事。事实上确实有人做过，也把patch发到UBI项目，但被拒了，好像是由于几个很小的问题，包括代码格式等等。其实那些UBI家伙根本不想（或这不屑？）去实现FTL界面，他们的逻辑是：FTL是给legacy filesystem用的，既然有更好的flash-aware-filesystem，为什么不用？FAT？不是应该扔垃圾堆了么？....他们在无视某些东西。

丑陋的妥协方案

项目不能等UBI家伙们实现FTL，而自己实现时间上不允许。只能用丑陋的妥协方案：

1）在NAND上安装YAFFS2（over mtd）

2）在YAFFS2分区上创建一个文件，attach一个loop device到这个文件。 3）对这个loop device运行fdisk创建分区，格式化等。

4）重新attach loop device到这个文件（从分区偏移量处开始）。 5）mount FAT到这个loop device上进行读写。

6）要通过USB访问时，指定usb mass storage模块的file参数到此文件上即可。

这些工作通过几个简单的脚本即可完成。

这个方案的优点是借用YAFFS2实现了负载均衡，缺点是透过loop device来安装FAT文件系统性能差。实际测试，通过USB传输大约仅300KB/s （ARM9, 200MHZ, USB 2.0 full speed）。而如果通过mtdblock而不是loop mount的话，可以达到700KB/s.

6.UFFS

UFFS特性介绍

UFFS是一个专门为NAND Flash设计的嵌入式文件系统，她具有一些非常诱人的特性以适合嵌入式应用： * 超低内存需求: （下表是一些典型配置情况下的内存需求） NAND flash | Total Blocks | Buffers/Caches | Total RAM cost 128M | 8192 | 40/30 | 164K 32M | 2048 | 40/30 | 68K 16M | 1024 | 10/10 | 26K 关系树结点: 16 * toatl_blocks

页缓存: page_size(512) * buffers (10 ~ pages_per_block) 块信息缓存: (14 * pages_per_block) * block_info_caches ( 5 ~ 20) 总内存需求 = 关系树结点 + 页缓存 + 块信息缓存 + 其它(1~2K)

由于所需内存很少，因此UFFS可以应用在一些对内存使用比较苛刻的场合，例如有些MCU仅有数十KB至一百多KB

的内置SRAM, 无需外扩内存即可使用UFFS管理大容量NAND Flash。UFFS内部使用更高效的方法管理树结点和缓冲区内存，在启动时就一次性分配好要使用的内存。一旦分配内存此后便不再改变（上表所列内存即为最大使用内存），这些内存直至卸载UFFS时才全部释放，因此UFFS可以采用静态内存分配，以适应无法提供动态内存分配器的系统（例如有些高可靠系统上禁止使用动态内存分配）。

* 快速启动

不象YAFFS在启动时需要读取所有Spare区，UFFS在启动时每个块仅需读取一至两个Spare即可，因此可以实现快

速启动。典型情况下，装载(mount) 128M字节满负荷的UFFS分区仅需要不到1秒。

* 高鲁棒性

UFFS采用日志式更新算法，任意时刻意外断电，UFFS文件系统可保持完整性。意外断电时，仅处于缓冲区内的部分

数据丢失，在下次启动时，UFFS会自动回滚到最后一次成功写入的状态。

* 坏块管理，ECC校验和纠错，负载均衡

这些特性对于Flash文件系统来说不算什么新鲜，但是UFFS以一种简单却非常有效的方式实现了他们。 * 无需额外的垃圾回收

因NAND Flash的擦除速度极快，UFFS采用边写入边动态回收“脏”的块的方法，因而无须额外的垃圾回收机制。 * 可支持直接“裸”Flash接口，无须操作系统支持

UFFS支持通过I/O口线连入系统的“裸”Flash接口，只需实现简单的\读／写／擦除\等操作即可，适合在小型RTOS甚

至无OS的情况下使用。

* 支持多分区，多种NAND Flash

UFFS支持多个分区，每个分区以一个虚拟目录的形式mount到根目录下。UFFS支持多种NAND Flash芯片，允许不

同的分区使用不同类型的FLASH芯片。 目前UFFS内置支持多数Samsung NAND Flash,包括small page(512)和large page(2048).

* 测试完备

UFFS可以在附带的PC模拟器（用PC上的一个文件模拟Flash芯片）上方便测试。目前已经有超过万台的嵌入式设备

使用UFFS作为大容量NAND Flash文件系统。

为何发起UFFS项目？

* 一些嵌入式系统RAM资源有限，但希望在NAND Flash上建立高度可靠的文件系统。 * JFFS/JFFS2 消耗太多内存，而且不容易移植到不具备OS的嵌入式系统上。

* YAFFS/YAFFS2 是一个非常优秀的可适合NAND Flash的文件系统，但是 依然需要消耗不少内存 * 其他？擅未发现有类似的开源项目.... 何处可以获得UFFS ？

目前你可以从 sourceforge.net (http://www.sourceforge.net/projects/uffs)上下载UFFS的所有资源. 一些

bug

总是在最新的

SVN

库里面得到最先修正。目前最新的

SVN

库地址：

https://uffs.svn.sourceforge.net/svnroot/uffs/branch/dev-uffs-1.1.1

工作原理 请参考这份文档:

?

Understanding UFFS ( PDF format )

在PC上尝试UFFS

Compile and run UFFS test shell:

?

Linux:

cd path_to_uffs/

. ./prepare.sh ./configure && make ./src/emu/uffs

?

Windows:

Open the Visual Studio C++ 6.0 project file: path_to_uffs/vcprj/uffs/uffs.dsp 移植到嵌入式系统

? ?

Modify uffs_os.c for your embedded software environment.

Create the flash interface file in which implement all member of \partition/mount point configuration. (see: src/example/flash-interface-example.c)

新加入一种NAND Flash类型

? ? ?

Create Flash class file: uffs_nand_xxxx.c (see: uffs_nand_samsung.c) Add the new flash class to \

Create the low level flash operation interface. (see: src/example/flash-interface-example.c)

如何支持UFFS？

使用UFFS，或者发现并报告bug给我 :-)

? ?

Bug reports please to: http://www.sourceforge.net/projects/uffs Talk to me directly on MSN: superzgz@hotmail.com

有问题？

?

Google group: http://groups.google.com/group/uffs

下一个版本: UFFS2

The main improvement on UFFS2 will be:

*The smaller memory footprint: reduce 25% memory usage as a result.

*One or more files/directories reside on one block, will significantly improve space efficiency for small files. *Symbol link or other special files.

*ECC data on page area or on spare (page area only for UFFS1) *Support NandOne and more NAND flash chips ...

7.FAT

目前嵌入式设备的Flash文件系统主要有3种：M-Systems公司的TrueFFS、JFFSx以及唯一专门针对NAND F1ash设计的YAFFS。这3种Flash文件系统都引入了日志结构的思想，其巾JFFSx和YAFFS是代码开源的。

现在大多数嵌入式手持设备上的操作系统采用FAT文件系统，而DOS下通用的FAT文件系统并不适合直接移植到Flash存储器中．主要有以下3个原因：第l，嵌入式系统的应用条件恶劣，电源电压不稳定，突发性断电以及非法插拔都将对Flash的存储造成灾难性的影响；通用文件系统对于可靠性的设计考虑不足。第2，通用文件系统的记录信息需要被多次改写(如FAT表)，而记录信息放在固定的区块中，将导致该区块的频繁使用，影响整个Flash器件的使用寿命。第3，Flash存储器读取速度比磁盘驱动器快，存储的内容很多是多媒体数据资料。这些数据允许一定程度的误码率，未必需要像通用文件系统那样严格保证存储的正确性。如果通过灵活的校验机制与坏损管理，则可以达到更高效的存储空间利用率。这对成本敏感的嵌入式系统来说是更加需要考虑的。

针对上述情况，本设计构建了一个适合NAND Flash存储器的FAT文件系统。针对其存储特点，对FAT表和FRT表的存储方式进行了改进，延长了使用寿命，增强了可靠性，使之更有利于Flash存储器的应用。 3 FAT文件系统的结构

FAT文件系统技术成熟、结构简单、系统资源开销小，易于在嵌入式系统的硬件平台上实现。 文件系统由以下4部分组成：

O——系统记录区(System Record Region)； 1——FAT表区(FAT Region)；

2——文件登记表区(File Register Table Region)； 3——数据区(Data Region)。

①系统记录区(System Record Region，SR)存放最重要的文件系统信息，如Flash存储器的类型、容量、版本信息、数据区域的位置和大小，还包括分区表和主引导程序。主引导程序的任务是检查分区表是否正确，自动读取

FAT表和FRT表，将其复制到控制终端的内存中。

②文件分配表(File Allocation Table，FAT)存放Flash存储器上所有区块的占用与空闲情况以及每个文件的存储连接结构。FAT文件系统中有12位、1 6位、32位3种不同的格式。不同格式的文件系统管理存储单元的个数不同，如FATl6文件系统采用16位字长的分配表，最多可以管理2的16次方(65536)的基本存储单元。

③文件登记表(File Register Table，FRT)紧跟在FAT表之后．存放F1ash文件系统中每一个文件的代号、长度、属性、目录、生成或最后修改的时间，以及该文件的存储链在文件分配表中的入口。 ④数据区域(Data Region)用于存放数据。本Flash文件系统中，数据分配的最小单位是Flash存储器的一个基本擦除单元，即一个物理区块(block)。

考虑到文件系统在嵌入式设备上实现的方便性并权衡Flash存储器的应用规模．选择、建立FATl6文件系统。

4 FAT文件系统的改进设计

当文件系统工作时，发生变化的只有FAT表和紧跟在其后的FRT表，因此，只用跟踪记录FAT表和FRT表就能知道文件操作的具体情况，这也是文件系统的核心；但Flash存储器结构与硬盘不同，不能直接改写其内容。直接移植的FAT文件系统、FAT表和FRT表始终存放在同一个区块中，将会导致该区块的使用寿命明显比其他的区块短。如果这一重要区域失效，那么将影响整个存储器的使用，因此必须改进两个表的存储方式。

Flash生产厂商设定的存储空间的第l区块必定是有效块。在改进的设计中，将第1个区块(128KB+4KB)作为存储器的系统记录区，同时在此区块中建立一个100KB(50页)的空白区域，用于记录FAT表在Flash中的起始地址(FRT表紧跟FAT表之后，不必再单独记录其首地址)。按照写入操作以页为单位的规则，100 KB的空间，可以加入FAT表的起始地址50次。 FIash第1块的分配信息区结构如图1所示。

改进设计的文件系统把FAT表和FRT表作为可移动的数据放在某一个区块内，在Flash的系统信息区中记录着FAT表的首地址，并用指针指向它。每次FAT表存储的位置发生变化时，只需将新位置的首地址添加到系统信息区的空白区域中，再调整指针的指向。这样避免了FAT表和FRT表始终在一个区块中反复擦写，导致该区块被过度使用，缩短存储器的寿命。文件系统的操作原理框网如图2所示。

图2中，主引导区程序首先读出存储在系统信息区中FAT表的首地址，找到FAT表和FRT表，再将其复制到控制终端的内存中进行操作(内存中可以按位修改，避免Flash不能按位修改的问题)。由于FAT文件系统是索引的链式结构，在内存中修改FAT表和FRT表的同时，也将两个表的改写情况以链式的方式紧跟在Flash存储器中两个表后面的空白区域里。这样在任何时候发生突然掉电或非法插拔而导致内存中FAT表和FRT表丢失的情况下，也能根据Flash中改写的内容恢复两个表，提高文件系统的可靠性。 在全部操作完成后，先把内存中的FAT表和FRT表写到存储器的转存区块中，擦除原来表所在的区块，再将转存区块中的内容复制到擦除后的原区块中。最后，擦除转存区块，完成整个一次操作。

同时，为了避免表存储区块的过度使用，当其擦除操作次数到了一个阈值(如500000次)时，先将FAT表和FRT表移动到其他空白区块，新区块作为表的存储区块。再把其中FAT表的首地址，写到FIash存储器的系统信息区的预留空白区域中，通过变化指针，程序在下次操作时将读取新地址。原先存放FAT表和FRT表的区块被标志为无效，最后通过Flash的垃圾回收策略，回收此区块。这样可达到将FAT表和FRT表作为移动数据存储的目的，延长了使用寿命，如图3所示。

上面的设计中，存储器第l区块作为信息记录区块。其中的预留空白空间可以记录50个地址，可以满足FAT表和FRT表移动5O次。表存储区块的使片j寿命提高了5O倍。

经过上面的改进，文件系统不仅避免了FAT表和FRT表始终在一个块中被过度使用的现象，也避免了在任何时候，发生掉电或非法插拔的情况。仍然可以根据Flash中修改过的内容重新建立新的FAT表和FRT表，使文件系统不至于遭到致命的破坏。这样虽然占用了一些Flash资源，但确保了文件系统的安全性和

可靠性。通过这样的没计，即使出现了操作异常的情况，错误也只涉及当时被操作的文件，不会扩散给F1ash存储器中的其他文件，更不会因此彻底损坏FAT表和FRT表，造成整个文件系统的瘫痪。

本文来源：https://www.bwwdw.com/article/zodw.html