The Linux MTD, JFFS HOWTO - (第2部分) FAQ (未完待续 2007/2/27)
[本文第一部分] The Linux MTD, JFFS HOWTO - (第1部分) HOWTO*** FAQs:Q. 什么是MTD?为什么我们需要MTD?A. 来自MTD网站: “我们的专注于建立一个关于内存设备的通用Linux子系统,特别针对Flash设备。 这个系统通过为硬件驱动和上层软件提供通用接口,使之能够简单的为新硬件提供驱动。 硬件驱动不需要了解(内存设备)使用哪种
·
[
本文第一部分]
The Linux MTD, JFFS HOWTO - (第1部分) HOWTO
*** FAQ's:
Q. 什么是MTD?为什么我们需要MTD?
A. 来自MTD网站:
“我们的专注于建立一个关于内存设备的通用Linux子系统,特别针对Flash设备。
这个系统通过为硬件驱动和上层软件提供通用接口,使之能够简单的为新硬件提供驱动。
硬件驱动不需要了解(内存设备)使用哪种存储格式,如FTL,
FFS2等等,它只需要提供简单的读、写以及擦除程序。由上层软件来把设备中的信息以适当的形式显示给用户。”
Q. 什么是JFFS?
A. JFFS是Axis Communications AB, Sweden(www.axis.com)设计的。它是一种开源日志文件系统,非常适于放在Flash芯片上。想了解更多详细信息,请看:
http://developer.axis.com/software/jffs/
其它相关文档(没有审视过,也没有链接指向它):
http://developer.axis.com/software/jffs/doc/jffs.shtml
David Woodhouse在jffs邮件列表的一封邮件中这样描述jffs:
“JFFS完全是日志结构的。这个文件系统在flash媒介上的一大串结点。每一个结点(struct
jffs_node)都包含它所属文件(严格说,是inode)的部分信息,可能也包含文件的名字,或文件的数据。当jffs_node保存了文件中的数据时,它会包含一个字段表明这些数据在文件所处的位置。通过这种方式,新的数据能够覆盖老的数据。
除于具有通常inode所具有信息之外,jffs_node中还包含了一个字段,用于表示在这个结点的偏移上,此文件有多少数据被删除了。这种机制用于截短文件等操作。
每个结点也包含一个“version”,当对文件的第一个结点,它为1;每当有一个新的结点被加入文件,这个数字递增1。不需要关心这些结点的物理顺序,它只是用于保持擦除级别,我们从开头开始擦除,一直擦除到最后。
当重建一个文件的内容时,你可以扫描整个媒介(看一下jffs_scan_flash(),它在mount时会被调用),然后按“version”递增的顺序排列单个结点。解析每个结点的内容找到你应该在哪里插入/删除数据。当前的文件名保存在最近的一个包含“name”字段的结点中。
(这并不是微不足道的。举个例子,如果你有一个文件中包含1024字节的数据,那么当你再把512字节的数据写到文件偏移256处时,你会得到两个结点
---
其中一个包含偏移0到偏移1024的数据,另外一个结点包含偏移256,长度为512字节的数据,以及标明从偏移256处删除512字节。实际上,你的第一个结点中的数据出现在这个文件的两个位置:从0-256字节以及从768-1024字节。JFFS代码使用struct
jffs_node_ref来处理这种情况,并保存组成这个文件的结点的一个列表。)
所有这些都非常简单,直到你巨大的结点列表到达了媒介的结尾。在这种情况下,我们不得不再次媒介的起始处开始。位于第一个擦除块中的结点,内容可能已经陈旧了,为新的结点所替代。所以在我们真的到达文件的结尾写满整个文件系统之前,我们把第一个块内依旧有效的结点拷贝出来,然后擦除原来的块。期望这样可以回收到一些空间。如果没有,我们继续处理下一个块,以此类推。这叫做垃圾回收。
我们要保证避免把位于“头”(我们在这里写入新的结点)和“尾”(它指向最老的结点)之间的空闲空间耗尽。一旦出现这种情况,那意味着我们完全不能进行垃圾回收了,所以文件系统就会始终保持这个样子,即使它里面的某个地方还存在着废弃的结点。
尽管当前我们由起始处开始写,直到结尾处。其实,我们应该独立的处理每个擦除块,为擦除块保持一个各种状态的列表(空闲/正在填充/已满/废弃/正在擦除/坏块)。通常,擦除块将沿着“空闲-->正在擦除”的路线前进,最终再回到“空闲”状态(当重写任何有效结点到“正在填充”结点时,擦除块的状态会由“已满”变成“废弃”)。”
(未完待续)
*** FAQ's:
Q. 什么是MTD?为什么我们需要MTD?
A. 来自MTD网站:
“我们的专注于建立一个关于内存设备的通用Linux子系统,特别针对Flash设备。
这个系统通过为硬件驱动和上层软件提供通用接口,使之能够简单的为新硬件提供驱动。
硬件驱动不需要了解(内存设备)使用哪种存储格式,如FTL,
FFS2等等,它只需要提供简单的读、写以及擦除程序。由上层软件来把设备中的信息以适当的形式显示给用户。”
Q. 什么是JFFS?
A. JFFS是Axis Communications AB, Sweden(www.axis.com)设计的。它是一种开源日志文件系统,非常适于放在Flash芯片上。想了解更多详细信息,请看:
http://developer.axis.com/software/jffs/
其它相关文档(没有审视过,也没有链接指向它):
http://developer.axis.com/software/jffs/doc/jffs.shtml
David Woodhouse在jffs邮件列表的一封邮件中这样描述jffs:
“JFFS完全是日志结构的。这个文件系统在flash媒介上的一大串结点。每一个结点(struct
jffs_node)都包含它所属文件(严格说,是inode)的部分信息,可能也包含文件的名字,或文件的数据。当jffs_node保存了文件中的数据时,它会包含一个字段表明这些数据在文件所处的位置。通过这种方式,新的数据能够覆盖老的数据。
除于具有通常inode所具有信息之外,jffs_node中还包含了一个字段,用于表示在这个结点的偏移上,此文件有多少数据被删除了。这种机制用于截短文件等操作。
每个结点也包含一个“version”,当对文件的第一个结点,它为1;每当有一个新的结点被加入文件,这个数字递增1。不需要关心这些结点的物理顺序,它只是用于保持擦除级别,我们从开头开始擦除,一直擦除到最后。
当重建一个文件的内容时,你可以扫描整个媒介(看一下jffs_scan_flash(),它在mount时会被调用),然后按“version”递增的顺序排列单个结点。解析每个结点的内容找到你应该在哪里插入/删除数据。当前的文件名保存在最近的一个包含“name”字段的结点中。
(这并不是微不足道的。举个例子,如果你有一个文件中包含1024字节的数据,那么当你再把512字节的数据写到文件偏移256处时,你会得到两个结点
---
其中一个包含偏移0到偏移1024的数据,另外一个结点包含偏移256,长度为512字节的数据,以及标明从偏移256处删除512字节。实际上,你的第一个结点中的数据出现在这个文件的两个位置:从0-256字节以及从768-1024字节。JFFS代码使用struct
jffs_node_ref来处理这种情况,并保存组成这个文件的结点的一个列表。)
所有这些都非常简单,直到你巨大的结点列表到达了媒介的结尾。在这种情况下,我们不得不再次媒介的起始处开始。位于第一个擦除块中的结点,内容可能已经陈旧了,为新的结点所替代。所以在我们真的到达文件的结尾写满整个文件系统之前,我们把第一个块内依旧有效的结点拷贝出来,然后擦除原来的块。期望这样可以回收到一些空间。如果没有,我们继续处理下一个块,以此类推。这叫做垃圾回收。
我们要保证避免把位于“头”(我们在这里写入新的结点)和“尾”(它指向最老的结点)之间的空闲空间耗尽。一旦出现这种情况,那意味着我们完全不能进行垃圾回收了,所以文件系统就会始终保持这个样子,即使它里面的某个地方还存在着废弃的结点。
尽管当前我们由起始处开始写,直到结尾处。其实,我们应该独立的处理每个擦除块,为擦除块保持一个各种状态的列表(空闲/正在填充/已满/废弃/正在擦除/坏块)。通常,擦除块将沿着“空闲-->正在擦除”的路线前进,最终再回到“空闲”状态(当重写任何有效结点到“正在填充”结点时,擦除块的状态会由“已满”变成“废弃”)。”
(未完待续)
更多推荐
已为社区贡献2条内容
所有评论(0)