YAFFS A NAND flash filesystem
几种Nand flash文件系统的对比
几种Nand flas文件系统的对比来源：NLE-FFS: A Flash File System with PRAM for Non-linear EditingFor thesedevices, NAND flash memory has became the most attractive storage medium due to outstanding characteristics such as its increased capacity, low power consumption, small size and light weight. For the efficient management of NAND flashmemory, several flash file systems have been proposed, including JFFS2, YAFFS2, CFFS and PFFS. several file systems such as MNFS,NAMU and ScaleFFS have been designed forreal-time recording /playback and large-capacity storage. A. YAFFS2YAFFS2 is the most widely employed file system for NAND flash memory. YAFFS2 essentially saves the object ID (file ID) and the chunk (page) number in the spare region to show the offset of a page and the owner file of the page. Therefore, YAFFS2 reads the spare regions and object headers to establish the metadata in memory.Although YAFFS2 is designed to support NAND flash memory, it has scalability problems. With YAFFS2, the location of the updated page is saved in NAND flash pages or spare regions, as shown in Fig. 10 (a); hence, the file systemshould scan the entire flash space at the mounting time. Moreover, the entire directory and file system structures must be saved in main memory at that time. Thus, the mounting time and the memory usage are increased linearly according to the NAND flash size and the number of files.YAFFS2 has another problem in which many pages are consumed during metadata updates. The metadata are frequently updated and most of the metadata updates are performed in several bytes. Metadata updating creates large numbers of invalid pages. This severely degrades the write performance due to garbage collection, as byte-level updates and in-place updates are not allowed in NAND flash.B. PFFSTo address the problems with YAFFS2, PFFS wasproposed [4]. In PFFS, an architecture using PRAM and NAND flash memory is employed. In this file system,metadata are separated and stored in the PRAM region,whereas the other data are stored in the NAND flash memory region, as shown in Fig. 10 (b). Metadata separation has two advantages. First, the overhead of metadata updates is reduced. As shown in Fig. 10 (a),YAFFS2 writes 2KB of a NAND flash page for each metadata update. As the metadata are frequently updated and most of the metadataupdates are performed in several bytes, metadata updates with YAFFS2 create many invalid pages. This leads to severe performance degradation due to garbage collection. However, PFFS writes metadata in units of bytes, as it maintains metadata in the PRAM region as shown in Fig. 10 (b). Consequently, metadata separation by PFFS reduces the number of page-writes on account of in-place updating and byte-level updating. Second, PFFS requires only a short mounting time and uses a fixed amount of memory, whereas other flash file systems such as YAFFS2 require a considerable amount of time to scan NAND pages to construct in-memory file and directory structures.However, PFFS is also a general-purpose file system; thus,it does not sufficiently consider NLE operations. In this paper,to effectively support NLE, NLE-FFS is proposed. It is based on the architecture shown in Fig.3.。
JFFS文件系统和YAFFS文件系统的比较
JFFS文件系统和YAFFS文件系统的比较NAND flash文件系统JFFS2和YAFFS比较JFFS是由瑞典的Axis Communications Ab公司开发的(1999,以GNU发布),针对flash设备的特性为嵌入式设备开发的.(我边上的兄弟曾想去那里作毕业设计)JFFS1和JFFS2的设计中都考虑到了FLASH的特性特别是满足了上述3个条件,包括了垃圾回收,坏块管理等功能. 这两种文件系统属于LFS(Log-structured File System).这种文件系统的特点是一旦数据出错,容易恢复,但是系统运行是需要占用一定的内存空间,这些空间就是用来存储”log”的.JFFS的缺点就是加载时间太长,因为每次加载都需要将FLASH上的所有节点(JFFS的存储单位)到内存,这样也占用了可观的内存空间.除此之外,”circle log”设计使得在对文件数据进行所有的数据都会被重写,这样造成不必要的时间,同时也会减少FLASH的寿命.JFFS2对JFFS1作了些改进,比如所需的内存变少了,垃圾回收机制也优化了.针对JFFS1,JFFS2的缺点,JFFS3出现了.YAFFS1 ">“Yet Another Flash File System”作者是新西兰的Charles Manning为一家名叫Alpha one 的公司(/)设计的,是第一个为NAND Flash设计的文件系统.共两个版本YAFFS1 和YAFFS2.YAFFS1支持512Bytes/Page的NAND Flash;后者YAFFS2支持2kBytes/Page的NAND Flash. YAFFS文件系统也属于LFS.跟其他文件系统比较,它具有更好的可移植性,甚至可以使用在没有操作系统的设备上(called “YAFFS/Direct”). YAFFS采用模块化设计,虽然最初是用在linux系统上的,但是也已经移植到其他系统比如wince.还有个突出的优点是它在mount的时候需要很少的内存.(如果是小页—512byte/page,每1MByte NAND大约需要4KBytes内存;大页需要大概1KBytes RAM/1MByte NAND) JFFS与YAFFS比较,两者各有长处. 一般来说,对于小于64MBytes的NAND Flash,可以选用JFFS;如果超过64MBytes,用YAFFS比较合适.。
Yaffs2文件系统中对NAND Flash磨损均衡的改进
Yaffs2文件系统中对NAND Flash磨损均衡的改进摘要：针对以NAND Flash为存储介质时Yaffs2文件系统存在磨损均衡的缺陷，通过改进回收块选择机制，并在数据更新中引入冷热数据分离策略，从而改善NAND Flash的磨损均衡性能。
实验借助Qemu软件建立Linux嵌入式仿真平台，从总擦除次数、最大最小擦除次数差值和块擦除次数标准差等方面进行对比。
实验结果表明，在改进后的Yaffs2文件系统下NAND Flash的磨损均衡效果有明显提升，这有益于延长NAND Flash的使用寿命。
关键词： Yaffs2文件系统；NAND Flash；垃圾回收；冷热数据0 引言NAND Flash存储设备与传统机械磁盘相比，具有体积小、存储密度高、随机存储和读写能力强、抗震抗摔、功耗低等特点[1]。
它被广泛用于智能手机、车载智能中心、平板电脑等智能终端中。
近年来，以NAND Flash为存储介质的固态硬盘也得到越来越多的应用。
目前Yaffs2文件系统(Yet Another Flash File System Two，Yaffs2)[1]是使用最多、可移植性最好的专用文件系统，在安卓、阿里云OS、Linux等嵌入式系统中都有使用。
在Yaffs2文件系统下以NAND Flash为存储介质时存在磨损均衡的缺陷，可通过对回收块选择机制作改进和引入冷热数据分离策略来提高磨损均衡的效果。
1 Yaffs2和Nand Flash关系这里以使用最多的Linux操作系统为实践，将Yaffs2文件系统移植到Linux操作系统中。
Linux系统通常可以分为3层：应用层、内核层和设备层，其中支持NAND Flash设备的Yaffs2文件系统属于内核层，。
最上层用户应用程序通过VFS(Virtual File System)提供的统一接口，将数据更新等文件操作传递给Yaffs2。
VFS代表虚拟文件系统，它为上层应用提供统一的接口。
嵌入式 NAND flash文件系统JFFS2和YAFFS比较
嵌入式NAND flash文件系统JFFS2和YAFFS比较JFFS是由瑞典的Axis Communications Ab公司开发的(1999,以GNU发布),针对flash设备的特性为嵌入式设备开发的JFFS1和JFFS2的设计中都考虑到了FLASH的特性特别是满足了上述3个条件,包括了垃圾回收,坏块管理等功能. 这两种文件系统属于LFS(Log-structured File System).这种文件系统的特点是一旦数据出错,容易恢复,但是系统运行是需要占用一定的内存空间,这些空间就是用来存储”log”的.JFFS的缺点就是加载时间太长,因为每次加载都需要将FLASH上的所有节点(JFFS的存储单位)到内存,这样也占用了可观的内存空间.除此之外,”circle log”设计使得在对文件数据进行所有的数据都会被重写,这样造成不必要的时间,同时也会减少FLASH的寿命.JFFS2对JFFS1作了些改进,比如所需的内存变少了,垃圾回收机制也优化了.针对JFFS1,JFFS2的缺点,JFFS3出现了.YAFFS1 ">“Yet Another Flash File System”作者是新西兰的Charles Manning为一家名叫Alpha one 的公司(/)设计的,是第一个为NAND Flash设计的文件系统.共两个版本YAFFS1 和YAFFS2.YAFFS1支持512Bytes/Page的NAND Flash;后者YAFFS2支持2kBytes/Page的NAND Flash. YAFFS文件系统也属于LFS.跟其他文件系统比较,它具有更好的可移植性,甚至可以使用在没有操作系统的设备上(called “YAFFS/Direct”). YAFFS采用模块化设计,虽然最初是用在linux系统上的,但是也已经移植到其他系统比如wince.还有个突出的优点是它在mount的时候需要很少的内存.(如果是小页―512byte/page,每1MByte NAND大约需要4KBytes内存;大页需要大概1KBytes RAM/1MByte NAND) JFFS与YAFFS比较,两者各有长处. 一般来说,对于小于64MBytes的NAND Flash,可以选用JFFS;如果超过64MBytes,用YAFFS比较合适.由于嵌入式系统自身存在一些特殊要求，使得一些传统的文件系统(如FAT、EXT2等) 并不十分适合。
YAFFS嵌入式文件系统原理分析
ＹＡＦＦｓ是一种类似于ＪＦＦｓ／ＪＦＦｓ２的专门为ＮＡＮＤ Ｆｌａｓｈ 设计的嵌入式文件系统。与专为ＮＯＲ Ｆｌａｓｈ而设计的ＪＦＦｓ相 比，它减少了一些功能，因此速度更快、占用内存更少。
表１ ＮＡＮＤ和ＮＯＲ两种Ｆｌａｓｈ技术比较
ＮＡＮＤ
ＮＯＲ
性能
读速度慢 写速度快 擦除速度４ｍ８ 大多数写入操作前先进行擦 除操作擦除单元更小题。当每次页被 重写时，ｓｅｒｉａｌＮｕｍｂｅｒ就增加一次，对比不同的ｓｅｒｉａＩＮｕｍｂｅｒ就
可以找出当前的页。 ｃｈｕｎｋＩｄ非Ｏ值说明这是个数据ｃｈｕｎｋ，并且标示这个
ｃｈｕｎｋ在文件中的位置（除文件头外文件的第一个ｃｈｕｎｋ其 ｃｈｕｎｋＩｄ就是１）。为。表示这个ｃｈｕｎｋ包含的是文件头信息。
表２ ｃｈｕｎｋ中字节分配
字节
用途
０．．５ｌｌ ５１２．．５１５ ５１６ ５１７
文件和文件头数据 标记 数据状态。如果超过４位是Ｏ，表示这一页是被 丢弃的 块状态
５１８．．５１９ 标记
５２０．．５２２ ５２３．．５２４
ｃｈｕＩｌｋ中第二个２５６字节数据的Ｅｃｃ 标记
５２５．．５２７ ｃｈｕｎｋ中第一个２５６字节数据的Ｅｃｃ
嵌入式蒸巯编程
ＥＭＢＥＤＤＥＤ ＳＹＳＴＥＭ ＰＲＯＧＲＡＭＭＩＮＧ
深入理解yaffs2文件系统（一）
深⼊理解yaffs2⽂件系统（⼀）深⼊理解yaffs2⽂件系统（⼀）1、Flash⽂件系统1.1、背景已经有多种flash⽂件系统(FFSs)或flash块驱动（在之上运⾏⼀个常规的FS），同时都有优点或缺点。
Flash存储器有⾮常多的限制，这⾥就不⼀⼀列举了。
已经有各种⽅法解决这些限制，以提供⼀个⽂件系统。
必须认识到，“flash”，包括NOR和NAND，各⾃有不同的限制。
很容易被专业术语“flash”误导，误以为⽤于NorFlash的⽅法也⽴即适⽤于NandFlash。
Nand块驱动⼀般采⽤FAT16作为⽂件系统，但不够健壮，也不够贴近Flash的特性。
这些块驱动通过⼀个“本地--物理”的映射层来仿真可写的、类似于磁盘扇区的块。
当使⽤FAT16时，这些⽂件系统⼯作的相当好，它们内存消耗⼩，代码尺⼨也很⼩。
但就像所有基于FAT 的系统⼀样，它们很容易损坏（如，丢失簇）。
其他的途径则是设计整个⽂件系统，不是基于块驱动，⽽且是flash友好的，这允许更多的余地来解决上述所提到的问题。
当前有两个linux⽂件系统能⾮常好的⽀持NorFLash，那就是JFFS以及它的升级版本JFFS2。
这两者都提供⽇志机制，⼤⼤的提升了健壮性，这也是嵌⼊式系统特别重要的⼀个特性。
不幸的是，它们在RAM消耗和启动时间⽅⾯都不是很好。
JFFS在flash中的每⼀个journalling⽇志节点，需要⼀个基于RAM的jffs_node结构，每⼀个节点为48字节。
JFFS2做了⼀个⼤改进，通过剪裁相关的结构体（jffs2_raw_node_ref）⽽减少到16字节。
即使如此，在512字节页⼤⼩128M的NandFlash，按平均节点⼤⼩来算，也需要250000字节约4M⼤⼩。
JFFS和JFFS2在启动时，需要扫描整个flash阵列来查找journaling节点，并决定⽂件结构。
由于NAND容量⼤、慢、连续访问、需要ECC校验，这些特性将导致不可接受的、很长的启动时间。
YAFFS文件系统简介
YAFFS文件系统简介一、YAFFS文件系统简介YAFFS(Yet Another Flash File System)文件系统是专门为NandFlash设计的文件系统，有些类似与JFFS/JFFS2文件系统，不同之处是JFFS/JFFS2文件系统最初是为NorFlash的应用场合设计的，而NorFlash和NandFlash本质上有较大的区别（坏块、备用区、容量），所以尽管JFFS/JFFS2文件系统也能应用于NandFlash，但由于它的内存占用和启动时间针对NorFlash做了特殊取舍，所以对于NanFlash来说通常不是最优方案（性能较低和启动速度稍慢）。
而YAFFS利用NandFlash提供的每个页面16字节或64字节的Spare区（备用区）空间来存放ECC和文件系统的组织信息，能够实现错误检测和坏块处理。
这样的设计充分考虑了NandFlash以页面为存取单元的特点，将文件组织成固定大小的数据段，能够提高文件系统的加载速度。
（垃圾回收算法+贪心算法）YAFFS目前有YAFFS、YAFFS2两个版本（YAFFS3还在研发阶段，没有面市），一般来说，YAFFS对小页面（512B+16B/页）有很好的支持，YAFFS2对更大的页面（2K+64B/页）支持更好。
二、YAFFS文件系统在NandFlash上的组织方式YAFFS对文件系统上的所有内容（比如正常文件，目录，链接，设备文件等等）都统一当作文件来处理，每个文件都有一个页面专门存放文件头，文件头保存了文件的模式、所有者ID、组ID、长度、文件名、Parent Object ID等信息。
因为需要在一页内放下这些内容，所以对文件名的长度，符号链接对象的路径名等长度都有限制。
YAFFS充分利用了NandFlash的“备用区”空间，这个备用空间是指每个页的16自己的Spare区，通常不作为存储数据的空间。
YAFFS用了其中的6个字节作为页面数据的ECC，1个字节用作坏块状态标志字，1个字节用作数据状态标志字，其余的8个字节用来存放文件系统的组织信息。
yaffs2文件系统实现原理分析
1 概述YAFFS （Yet Another Flash File System ）文件系统是专门针对NAND flash 设计的嵌入式文件系统，目前有YAFFS 和Y AFFS2两个版本，两个版本的主要区别之一在于Y AFFS2 能够更好的支持大容量的NAND flash 芯片。
YAFFS 文件系统有些类似于JFFS/JFFS2文件系统，与之不同的是JFFS/JFFS2文件系统最初是针对NOR flash 的应用场合设计的，而NORflash 和NAND flash 本质上有较大的区别，尽管JFFS/JFFS2文件系统也能应用于NANDflash ，但由于它在内存占用和启动时间方面针对NOR 的特性做了一些取舍，所以YAFFS2对NAND flash 来说通常才是最优的选择方案。
2 相关概念分析YAFFS2之前，把NAND flash 相关概念介绍下：NAND flash 由块(block)组成，块又由页(page)构成，擦除时以块为单位，读写时以页为单位，页又包含数据区和空闲区(OOB,Out-Of-Band)，而Page 在YAFFS2中被称为Chunk ，其中的数据区用来存放实际的数据，OOB 用来存放附加信息实现NAND flash 的管理。
以T8000 AXMPFUA 单板使用的NANDflash 为例，每块Block: 128 pages ，每页Page: (8K + 448) bytes ，数据区为8K ，OOB 为448bytes ，如图1所示：Plane :4096blocks128 pages（8K+448）bytes图1 NAND flash 物理结构3 数据结构struct yaffs_dev 是YAFFS2文件系统最核心的数据结构，表示Y AFFS2文件系统的超级块，它建立了整个文件系统的层次结构，并衔接VFS 层和MTD 层，与struct super_block 、struct mtd_info 的关系如图2所示：图2 yaffs_dev与super_block、mtd_info层次关系下面围绕struct yaffs_dev这个最核心的数据结构开始，分段介绍它的含义，进而引出其他重要的数据结构：■param：存储文件系统重要的一些参数，以及与MTD层的接口函数□inband_tags：标志位，默认为0，即采用OOB（out of band）方式存储tags，可以通过挂载时指定inband-tags选项改变默认值□total_bytes_per_chunk：每个chunk总的字节数□chunks_per_block：每个block总的chunk数□spare_bytes_per_chunk：每个chunk包含OOB块的字节数□start_block：第一个可以使用的block□end_block：最后一个可以使用的block□n_reserved_blocks：为GC保留的block阈值□n_caches：缓冲区的个数，YAFFS2为减少数据的碎片以及提高性能为每个文件的写入提供了cache□no_tags_ecc：标志位，默认为0，即tags中包括ECC纠错信息，可以通过内核配置改变默认值，CONFIG_YAFFS_DISABLE_TAGS_ECC□is_yaffs2：标志位，默认为0，即Y AFFS，在挂载的过程中会根据识别的mtd->writesize自动转换成YAFFS2□refresh_period：刷新周期，刷新目的主要找出最旧的处于YAFFS_BLOCK_STATE_FULL状态的block，供GC作为gc_block使用□skip_checkpt_rd：标志位，默认为0，支持读取checkpoint，提高挂载速度的一个功能可以通过挂载时指定挂载选项no-checkpoint-read、no-checkpoint修改默认值□skip_checkpt_wr：标志位，默认为0，支持写入checkpoint，提高挂载速度的一个功能可以通过挂载时指定挂载选项no-checkpoint-write、no-checkpoint修改默认值□write_chunk_tags_fn：函数指针，在挂载的文件系统的时候会被初始，NANDflash写入接口函数：param->write_chunk_tags_fn = nandmtd2_write_chunk_tags;□read_chunk_tags_fn：函数指针，在挂载的文件系统的时候会被初始，NANDflash读取接口函数：param->write_chunk_tags_fn = nandmtd2_write_chunk_tags;□erase_fn：函数指针，在挂载的文件系统的时候会被初始，NAND flash擦除block接口函数：param->erase_fn = nandmtd_erase_block;□wide_tnodes_disabled：标志位，默认值为0，采用动态位宽，通过内核配置修改可采用静态位宽CONFIG_YAFFS_DISABLE_WIDE_TNODES■os_context:指向yaffs_linux_context结构指针，该结构存储Y AFFS2运行环境，如下：□context_list：通过该字段加入到yaffs_context_list全局链表中□dev：指向Y AFFS2文件系统超级块的指针□super：指向VFS层超级块的指针□bg_thread：Y AFFS2后台垃圾回收线程的指针□bg_running：启动和停止垃圾回收线程的标志位，1：启动，0：停止□gross_lock：互斥锁，保护整个超级块关键字段的互斥访问，粒度比较大□spare_buffer：OOB块的缓冲区□search_contexts：通过该字段把所有Directory Search Context组成链表□yaffs_mtd_put_super：卸载文件系统时被调用来清理super_block□readdir_process：解决使用NFS死锁问题加入的□mount_id：每个NAND flash分区挂载YAFFS2都分配不同的ID号■driver_context：指向mtd_info结构指针，mtd_info是MTD子系统核心的数据结构，主要是对底层硬件驱动进行封装，这里不再介绍■data_bytes_per_chunk：每个chunk总的字节数，和前面提到的total_bytes_per_chunk一样■chunk_grp_bits ：采用静态位宽时超过tnode_width宽度之后的位数，采用动态位宽值恒为0■chunk_grp_size：由chunk_grp_bits转化而来的大小■tnode_width：采用静态位宽默认是16，采用动态位宽是由整个NAND flash中chunk数目计算得到■tnode_mask：位宽的mask，主要用于快速获取chunk id号■tnode_size：YAFFS_NTNODES_LEVEL0节点所占用的内存大小，单位:byte■chunk_shift：主要用来计算logical chunk index以及logical chunk offset■chunk_div：作用同chunk_shift，主要用于chunk大小不是2次幂的情况■chunk_mask：作用同chunk_shift，组合起来计算logical chunk offset■is_mounted：标志位，文件系统挂载时被置位Checkpoint是为提高挂载速度而引入的功能，作用同JFFS2的EBS，以空间来换取时间，卸载时通过在NAND flash上保存文件系统超级块快照，挂载时获取快照信息可以快速还原系统的状态。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
YAFFS-defined
Chunk - YAFFS tracking unit. usually==page. Can be bigger, e.g. 2x2K NAND in parallel as 4K chunks)
Project Genesis
Flash hardware
YAFFS fundamentals
Flash hardware
YAFFS fundamentals
Filesystem Details
Embedded Use
Design approach
OS and compiler neutral Portable - OS interface, guts, hardware interface, app interface Log-structured - Tags break down dependence on physical location Configurable - chunk size, file limit, OOB layout, features Single threaded (don’t need separate GC thread like NOR) Follow hardware characteristics (OOB, no re-writes) Developed on NAND emulator in userspace Abstract types allow Unicode or ASCII operation
Filesystem Details
Embedded Use
Process
Each file has an id - equivalent to inode. id 0 indicates ’invalid’ File data stored in chunks, same size as flash pages (2K/512 bytes) Chunks numbered 1,2,3,4 etc - 0 is header. Header gives type (device/file/dir) and hold mode/uid/length etc Each flash page is marked with file id and chunk number These tags are stored in the OOB - file id, chunk number, write serial/sequence number, tag ECC and bytes-in-page-used When changing a file the relevant chunks are replaced by writing new pages with new data but same tags - the old page is marked ’discarded’ Pages have a serial number incremented on write (2-bit serial in YAFFS1, sequence in YAFFS2). Allows crash-recovery when two pages have same tags. Discarded blocks are garbage-collected. Deleted items placed in ‘deleted’ dir (YAFFS2)
Chip Fault Yes Yes
Degredation Yes Yes
Prog/Erase failure Yes Yes
Leakage
Write Disturb
Read Disturb
Yes Future Future Yes Yes Future Yes Future Yes
Project Genesis
Project Genesis
Flash hardware
YAFFS fundamentals
Filesystem Details
Embedded Use
Log-structured Filesystem (1)
Imagine flash chip with 4 pages per block. First we’ll create a file.
2
3
4
5
Project Genesis
Flash hardware
YAFFS fundamentals
Filesystem Details
Embedded Use
Project Genesis
TCL needed a reliable FS for NAND Charles Manning is the man Considered Smartmedia compatibile scheme (FAT+FTL) Considered JFFS2
Better than FTL High RAM use Slow boot times
Project Genesis
Flash hardware
YAFFS fundamentals
Filesystem Details
Embedded Use
History
Decided to create ’YAFFS’ - Dec 2001 Working on NAND emulator - March 2002 Working on real NAND (Linux) - May 2002 WinCE version - Aug 2002 ucLinux use - Sept 2002 Linux rootfs - Nov 2002 pSOS version - Feb 2003 Shipping commercially - Early 2003 Linux 2.6 supported - Aug 2004 YAFFS2 - Dec 2004 Checkpointing - May 2006
Project Genesis
Flash hardware
YAFFS fundamentals
Filesystem Details
Embedded Use
Flash primer - NOR vs NAND
Access mode: Replaces: Cost: Device Density: Erase block size: Endurance: Erase time: Programming: Data sense: Write Ordering: Bad blocks: OOB data: NOR flash Linear random access ROM Expensive Low (64MB) 8k to 128K typical 100k to 1M erasures 1second Byte by Byte, no limit on writes Program byte to change 1s to 0s. Erase block to change 0s to 1s Random access programming None when delivered, but will wear out so filesystems should be fault tolerant No NAND flash Page access Mass Storage Cheap High (1GB) 32x512b / 64x2K pages 10k to 100k erasures 2ms Page programming, must be erased before re-writing Program page to change 1s to 0s. Erase to change 0s to 1s Pages must be written sequentially within block Bad blocks expected when delivered. More will appear with use. Thus fault tolerance is a necessity. Yes (16 bytes)
Project Genesis
Flash hardware
YAFFS fundamentals
Filesystem Details
Embedded Use
YAFFS A NAND flash filesystem
Wookey wookey@
Aleph One Ltd Toby Churchill Ltd
Flash Blocks Block 0 Chunk 0 ObjId 500 ChunkId 0 DelFlag Live Comment
Embedded Linux Conference - Europe Linz
Project Genesis
Flash hardware
YAFFS fundamentals
Filesystem Details
Embedded Use
1
Project Genesis Flash hardware YAFFS fundamentals Filesystem Details Embedded Use
Project Genesis
Flash hardware
YAFFS fundamenls
Embedded Use
Terminology
Flash-defined
Page - 2k flash page (512 byte YAFFS1) Block - Erasable set of pages (typically 64 on 2K NAND)
Project Genesis
Flash hardware
YAFFS fundamentals
Filesystem Details