NAND flash类文件系统

随着F2FS慢慢的进入android系统的视野。简单介绍一下NAND flash类文件系统的发展。

     在linux上，大家不可避免的遇到文件系统filesystem这个概念，这个概念在之前的windows上基本没有遇到过，因为windows将其支持的文件系统限定在fat/NTFS/Exfat上。比较单一化。如果查看一下linux的fs目录，一看吓一跳。至少几十个目录，基本一个目录就代表一种文件系统类型。

    那么什么是文件系统？个人认为文件系统代表着在存储介质上组织数据的一种方式。其不可以避免的跟存储设备的类型有着莫大的关系。同样的存储设备，采用不同的文件系统，其性能也稍有差异。同时文件系统的一些设计同样影响着性能。
    大家都知道NOR和NAND flash。其中NOR flash被用作片上存储区，而NAND flash被用作外部存储器。由于NAND flash独特的page/block特性，给文件系统带了一些挑战。首先NAND flash不像磁盘一样可以直接update修改数据。如果NAND flash需要更新数据，必须read->erase->write来更新数据。由于read/write的最小单元是page，而erase的最小单元是block（1 block = 32/64/128 pages）。这种操作尺寸的不一致，导致NAND flash数据更新比较繁琐，比较频繁而效率低下。所以文件系统在设计上需要充分考虑存储介质的特性。

最初的yaffs（Yet Another Flash File System， 名字很任性，有没有)以及UBIFS（Unsorted Block Image File System）文件系统都是基于NAND flash的文件系统。他们都是基于linux的MTD（memory technology device）层接口而实现。其中MTD是linux构建的对于NAND的一个中间抽象层，封装了对于NAND flash的读写擦除等操作，向上层文件系统隐藏了具体驱动的实现细节。

除了上面提到的NAND flash读写/擦除尺寸的不一致，NAND flash还有一个特性：每一个块都有固体的擦除寿命，具体根据类型而已，比如SLC类型的NAND flash的寿命大约是10万次。就是说NAND flash的每一个block在大约擦除10万次之后就失去功能，成为一个坏块。

由于上述的两个特性，使得NAND flash文件系统需要格外小心处理。使得其实现跟之前的块设备类文件系统有着很大的差异。比如由于NAND flash的数据更新流程为read->erase->write,因此NAND flash文件系统大多采用了逻辑块到物理块的映射，来提高数据更新的效率。并且采用均衡损耗模型来提高NAND 设备的整体寿命。

如果想要在NAND flash存储器上支持块设备类文件系统比如FAT 或者EXT3/4.就需要软件实现一个FTL（flash translation layer）转换层，将MTD的读写擦除操作封装成为块设备的读写接口，并实现对于NAND flash Block块的管理。

随着发展，越来越多的厂商将FTL直接集成在存储设备内部的firmware，使得NAND flash本身成为一个块设备，最典型就是SD卡跟EMMC。各大厂商的firmware实现互不相同，性能也各有差异。这时候问题来了，虽然EMMC是块设备，但是它是基于NAND flash的块设备。其NAND flash的特性不可避免了影响着文件系统的性能，而传统的EXT文件系统是为传统块设备（比如磁盘）而设计的。

所以现在各大手机厂商渐渐的将目光注意到了F2FS(Flash Friendly File System).