"JFFS2源代码情景分析：数据实体及内核描述符详解（Beta2）"

需积分: 0 102 浏览量更新于2024-01-21 1 收藏 2.34MB PDF 举报

"JFFS2源代码情景分析1；声明你可以自由地随意修改本文档的任何文字内容及图表，但是如果你在自己的文档中以任何形式直接引用了本文档的任何原有文字或图表并希望发布你的文档，那么你也得保证让所有得到你的文档的人同时享有你曾经享有过的权利。目录声明你可以自由地随意修改本文档的任何文字内容及图表，但是如果你在自己的文档中以任何形式直接引用了本文档的任何原有文字或图表并希望发布你的文档，那么你也得保证让所有得到你的文档的人同时享有你曾经享有过的权利。 JFFS2源代码情景分析（Beta2）作者在www.linuxforum.net上的ID为shrek2 欢迎补充，欢迎批评指正！前言（new）本文旨在对JFFS2文件系统的源代码进行情景分析，并提供对代码的深入理解和解释。JFFS2是一种针对闪存设备的日志型文件系统，广泛应用于嵌入式系统中。通过对JFFS2的源代码进行情景分析，我们将可以了解其内部工作原理和逻辑。本文将从数据实体及其内核描述符开始讨论。第1章在第一章中，我们将聚焦于JFFS2的数据实体及其内核描述符。数据实体是JFFS2文件系统中最基本的单位，它负责存储文件和目录的内容。而内核描述符则是对数据实体进行管理和控制的结构。我们将讨论数据实体和内核描述符的结构、功能和相互关系，以便更好地理解JFFS2文件系统的实现。数据实体的内核描述符jffs2_raw_node_ref 数据实体的内核描述符jffs2_raw_node_ref是JFFS2中用于管理数据实体的重要结构。它包含了数据实体的元数据、位置信息和其他必要的属性。jffs2_raw_node_ref的设计目的是有效地存储和访问数据实体，保证其完整性和可靠性。通过对该结构的详细分析，我们将能够揭示JFFS2文件系统是如何管理数据实体的。结语通过本文对JFFS2源代码的情景分析，我们对JFFS2文件系统的内部机制有了更深入的了解。从数据实体及其内核描述符的分析，我们可以看到JFFS2文件系统是如何通过数据实体来存储和管理文件和目录的内容。这为我们使用和开发嵌入式系统提供了重要的参考和指导。希望本文对读者在理解和应用JFFS2文件系统方面有所帮助。欢迎补充和批评指正！"

第 2 章描述 jffs2te 特性的数据结构

void *os_priv;

};

其中部分域的说明如下，其它域的作用放到代码中说明：

文件系统是在具体设备上的特定数据组织形式。在向设备写入数据前，需要通过文件系统的相应方法将数

据组织为特定的格式；在从设备读出数据后，需要通过文件系统的相应方法解释数据，而真正访问设备的

工作是由设备驱动成完成的。jffs2 是建立在 flash 上的文件系统，所以向 flash 写入、读出数据实体的操作

最终通过 flash 驱动程序完成。jffs2_sb_info 的 mtd 域指向整个 flash（注意是包含若干分区的整个 flash）

的 mtd_info 数据结构，该数据结构在安装、初始化 flash 设备驱动程序时创建，提供了访问 flash 的方法。

从后文的读写操作分析可以看到，在向 flash 写入数据实体 jffs2_raw_inode 或者 jffs2_raw_dirent 及其后的

数据时，最终要调用 mtd_info 中的相应方法。

在文件系统所在的设备上索引节点号是惟一的，highest_ino记录了文件系统内最高的索引结点号。在ext2

中索引结点ext2_inode的编号由其物理位置决定，而且在分配其物理位置时出于效率因素要综合考虑多种

因素。而jffs2 中事情就简单多了：每当新建文件时为之分配的索引结点号即为highest_ino，并逐一递增该

域，参见下文

。

flags 为挂载文件系统时指定的各种标志，比如是否以只读方式挂载等等。

再次强调，一种文件系统是具体设备上的一种数据组织格式，因此必须针对具体设备的特点来设计文件系

统的数据结构。而文件系统的超级块从宏观上描述了整个文件系统，所以针对具体设备的特点所设计的数

据结构正体现在其超级块中。比如ext2 为用于磁盘的文件系统，所以在其超级块ext2_sb_info中包含了磁盘

分区上所有块组描述符、块组内索引结点的数量等与磁盘操作相关的数据结构。而jffs2 是应用于flash的文

件系统（有关flash的使用特点可参见讨论

），所以其超级块包含了针对flash使用特点的数据结构，主要可分

为三个部分：为了使各flash擦除块都被均衡使用的各种xxxx_list链表和GC内核线程，以及用于组织所有文

件的内核描述符的哈希表inocache_list，而文件描述符的主要作用就是描述一个文件的所有离散的数据结点

的位置等信息。下面我们逐一介绍这三个方面的数据结构。

为了尽量推迟写 flash 的时机（也可以提高写一个擦除块的效率），jffs2 使用一个内核线程来执行垃圾回收

( GC，即 Garbage Collecting)，在需要时回收所有过时的数据结点，比如剩余干净的擦除块数量过低时、卸

载 jffs2 时。创建这个内核线程后使用 gc_task 指向其 PCB，这样就可以直接给它发送各种信号从而控制其

状态了。相关的数据结构还包括 gc_thread_start 和 gc_thread_exit。信号量 gc_thread_start 用于保证在当前

进程（或 init 内核线程）在创建了 GC 内核线程后，在调用 kernel_thread 的函数返回前，GC 内核线程已经

运行了；gc_thread_exit 是一个 completion 数据结构，定义如下：

struct completion {

unsigned int done;

wait_queue_head_t wait;

};

其核心是一个等待队列 wait，整个数据结构由 wait.lock 保护。在 jffs2_stop_garbage_collect_thread 函数中

通过给 GC 内核线程发送 SIGKILL 信号来结束它，当前执行流在发送完信号后就阻塞在 gc_thread_exit.wait

等待队列上；而 GC 内核线程处理 SIGKILL 信号时将唤醒受阻的执行流并退出，详见后文分析。

没看懂

第 2 章描述 jffs2te 特性的数据结构

为了实现均衡地使用所有擦除块，jffs2 的方法必须记录各擦除块的使用情况和状态。这也就是各 xxxx_list

域和擦除块描述符数组 blocks[]的目的了。与此相关还包括若干 xxxx_size 的域，重新罗列如下：

uint32_t flash_size;

uint32_t used_size;

uint32_t dirty_size;

uint32_t wasted_size;

uint32_t free_size;

uint32_t erasing_size;

uint32_t bad_size;

uint32_t sector_size;

uint32_t unchecked_size;

其中 flash_size 和 sector_size 的值在挂载文件系统时由 jffs2_sb_info.mtd 所指向的 flash 板块描述符 mtd_info

中相应的域复制过来，分别代表 jffs2 文件系统所在 flash 分区的大小和擦除块的大小。

在 flash 擦除块描述符 jffs2_eraseblock 中就设计了 used_size、dirty_size、wasted_size、free_size 域，它们分

别表示当前擦除块内有效数据实体的空间大小、过时数据实体的空间大小、无法利用的空间大小和剩余空

间大小。其中“无法利用的空间”是由于 flash 上数据结点之间必须是 4 字节地址对齐的，因此在数据结

点之间可能存在间隙；或者由于填充；或者擦除块尾部的空间无法利用。那么 jffs2_sb_info 中这些域就是

分区上所有擦除块相应域的求和。

jffs2_eraseblock 数据结构为擦除块描述符，所有擦除块的描述符都存放在 blocks[]数组中。另外，根据擦除

块的状态（即是否有数据、数据过时情况等信息）还将擦除块描述符组织在不同的 xxxx_list 链表中，以供

文件系统的写方法和 GC 使用，从而实现对所有擦除块的均衡使用。根据作者的注释，各个 xxxx_list 域所

指向链表的含义如下：

链表链表中擦除块的性质

clean_list 只包含有效数据结点

very_dirty_list 所含数据结点大部分都已过时

dirty_list 至少含有一个过时数据结点

erasable_list 所有的数据结点都过时需要擦除。但尚未“调度”到 erase_pending_list

erasable_pending_wbuf_list 同 erase_pending_list，但擦除必须等待 wbuf 冲刷后

erasing_list 当前正在擦除

erase_pending_list 当前正等待擦除

erase_complete_list 擦除已完成，但尚未写入 CLEANMARKER

free_list 擦除完成，且已经写入 CLEANMARKER

bad_list 含有损坏单元

bad_used_list 含有损坏单元，但含有数据

最后，由于 jffs2 中不存在类似 ext_inode 的可以提供“索引”文件数据的机制，所以才在挂载文件系统时

不得不遍历整个 flash 分区，建立每个文件所包含数据实体的位置和长度信息。数据实体通过其所属文件

的内核描述符 jffs2_inode_cache 进行“索引”。所有文件的内核描述符被组织在一张哈希表中，即为

inocache_list 所指向的指针数组。

第 2 章描述 jffs2te 特性的数据结构

目录文件的内容由各目录项 jffs2_raw_dirent 数据实体组成，实现了“从文件名找到文件”的机制。在打开

文件、逐层解析文件的路径名时通过访问父目录文件即可得到当前文件的目录项实体 jffs2_raw_dirent，进

而得到文件的索引结点号 ino（path_walk 的细节可参见情景分析），然后通过 inocache_list 哈希表就可以得

到其 jffs2_inode_cache的指针，然后通过其 nodes 域得到文件所有数据实体的内核描述符 jffs2_raw_node_ref

组成的链表，从而最终得到所有数据实体在 flash 上的位置、长度信息。

文件索引结点的u域：jffs2_inode_info数据结构

在打开文件创建其 inode 时由具体文件系统提供的 read_inode 方法来初始化 inode 的 u 域。无论底层具体文

件系统中“索引结点”的形式如何，上层 VFS 的 inode 都完整、惟一描述了文件的所有管理信息（其在文

件系统内的组织信息由 dentry 描述），其中就必然包括索引文件数据的机制。由于在不同文件系统中数据

的组织、存储格式不同，索引文件数据的机制显然应该放到 inode 的 u 域中。比如 ext2 中通过 ext2_inode_info

的 i_data[]来索引文件数据所在的磁盘块，该数组内容从 ext2_inode 的 i_block[]数组复制过来；而 jffs2 中

通过 jffs2_inode_info 的 fragtree/metedata，或者 dents 来组织文件的所有数据实体的内核描述符。

struct jffs2_inode_info {

struct semaphore sem;

uint32_t highest_version; /* The highest (datanode) version number used for this ino */

rb_root_t fragtree; /* List of data fragments which make up the file */

/* There may be one datanode which isn't referenced by any of the above fragments, if it contains a metadata

update but no actual data - or if this is a directory inode. This also holds the _only_ dnode for

symlinks/device nodes, etc. */

struct jffs2_full_dnode *metadata;

struct jffs2_full_dirent *dents; /* Directory entries */

/* Some stuff we just have to keep in-core at all times, for each inode. */

struct jffs2_inode_cache *inocache;

uint16_t flags;

uint8_t usercompr;

#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,2)

struct inode vfs_inode;

#endif

};

由于inode的i_sem在generic_file_write/read期间一直被当前执行流持有，用于实现上层用户进程之间的同

步。所以在读写操作期间还要使用信号量的话，就必须设计额外的信号量。在jffs2_inode_info中设计的sem

信号量用于实现底层读写执行流与GC之间的同步。（这是因为GC的本质就是将有效数据实体的副本写到

其它的擦除块中去，即还是通过写入操作完成的，所以需要与其它写入操作同步，详见后文

。）

一个文件的所有数据实体（无论过时与否）都有唯一的 version 号。当前所使用的最高 version 号由

highest_version 域记录。

剩余149页未读，继续阅读

茶啊冲的小男孩

粉丝: 30
资源: 326

"JFFS2源代码情景分析：数据实体及内核描述符详解（Beta2）"

JFFS2源代码情景分析

jffs2源代码情景分析

jffs2 源代码情景分析

linux挂载jffs2

mkfs.jffs2

mkfs.jffs2 工具

mkfs.jffs2：未找到命令

直接解压jffs2 bin文件

如何编写bash脚本来运行fakeroot，并将rootfs打包成jffs2格式，最后退出fakeroot

petalinux使用jffs2文件系统

最新资源