本文通过分析ubifs的mount、read、write和commit流程，挖掘ubifs背后的设计决策和性能优化手段，并结合自身产品的特点，给出一些读写性能改进方案。
1. ubifs mount流程
mount过程就是初始化对象的过程。这其中包括上层（vfs层、页缓存层、通用块层）的回调接口的注册，从设备中获取相关信息（super block， master node，log，orphan， index node），初始化ubifs_info、TNC、LPT等内部对象，并对ubifs各区（默认不检查main区的index node，因为有log区的日志，一般情况下不需要扫描所有的index tree）、journal head、lpt head等进行校验、检查、修复、更新，创建后台进程等。可以看出，mount中包含了检查和修复过程，所以ubifs并没有提供额外的修复工具，这一点区别于vfat、ext3等文件系统。
mount的核心函数为ubifs_init，其主要负责外部对象的初始化，内部对象的初始化由ubifs_get_sb负责。具体细节如下：
ubifs_init主要流程：
- 创建ubifs inode slab（kmem_cache_create ）
- 注册ubifs TNC shrinker回收功能 ubifs_shrinker_info（register_shrinker ）
- 注册压缩算法（ubifs_compressors_init ）
- 注册debugfs（dbg_debugfs_init ）
- 注册ubifs文件系统 ubifs_fs_type（register_filesystem ）
- 调用ubifs_fs_type.ubifs_get_sb()继续初始化
ubifs_get_sb主要流程：
- 获取ubi_volume_desc对象
- 创建并初始化ubifs_info对象和super_block对象
- 读取并验证、修复ubifs_sb_node，并以ubifs_sb_node继续初始化ubifs_info对象
- 创建wbuf和后台线程ubifs_bgt1_0，其主要作用是后台同步write-buffers、commit、垃圾回收等。
- 读取并验证、修复ubifs_mst_node，并以ubifs_mst_node继续初始化ubifs_info对象
- 如果发现 index and LPT 头有损坏就进行修复，以继续初始化ubifs_info
- 更新master node信息
- 遍历、检查indexing node (ubifs_zbranch, ubifs_znode)的总大小是否与c->bi.old_idx_sz一致（dbg_check_idx_size，由chk_index控制，默认关闭）
- 回放log，检查修复index node，并更新TNC（ubifs_replay_journal）
- 删除orphan inode（ubifs_mount_orphans）
- 检查indexing tree的叶节点是否存在、crc等验证信息（dbg_check_filesystem，由chk_fs控制，默认关闭）
- 设置垃圾回收gc_waterline（UBIFS_FREE_RESERVE_RATIO 5），唤醒后台线程。
2. ubifs read流程
ubifs read按如下顺序，在存储层次中依次查找所需数据，直至找到并完成读取：
- page cache
- write buffer
- flash
ubifs一切数据都封装成node，不同类型的node有不同的长度。一个data node最大可以存储的数据大小为UBIFS_BLOCK_SIZE （4096）。也就是说ubifs单次读的最大长度即block大小。
ubifs读系统调用路径如下：read -> do_sync_read -> aio_read -> generic_file_aio_read -> generic_file_aio_read -> do_generic_file_read -> readpage -> ubifs_bulk_read 或 do_readpage
do_readpage：读取一个内存page，ubifs按block大小，把page切分成ubifs block后再依次按block进行读(read_block)。
ubifs_bulk_read：如果data node连续并在同一个LEB中，并超过3个内存page及以上（read_in_a_row控制），自动启动bulk_read。或者在mount时可以指定bulk_read option使能bulk read功能。bulk read最多支持UBIFS_MAX_BULK_READ(32) 个block的连续读。
3. ubifs write流程
ubifs write按如下顺序，在存储层次中依次写入，直至写到flash中：
- page cache
- write buffer
- TNC
- log area
- main area
ubifs wirte系统调用过程如下：
write -> do_sync_write -> aio_write -> ubifs_aio_write -> generic_file_aio_write -> __generic_file_aio_write -> generic_file_buffered_write -> generic_perform_write
ubifs wirte分为三个阶段：write_begin， write_end， writepage。
write_begin阶段主要做2件事：获取并更新page，flash空间预算申请。详细流程如下 :
- 查询cache page，如没有就创建一个；如果page需要update，调用do_readpage从flash读取数据更新page，
- 为page申请flash上的budget空间，如果page appending 没置位或者ui->dirty置位，则不需要为此page申请budget，否则调用allocate_budget申请budget，流程如下：a）如果没有新数据，则返回成功
b）如果flash空间足够，则返回成功
c）如果fast budgeting，因为页缓存已经锁定，不能触发后面流程，只能直接返回错误
d）脏也写回flash（shrink_liability）
e）垃圾回收（0run_gc）
f）内存数据提交（ubifs_run_commit） - 如果allocate_budget失败，释放之前申请的页缓存，并调用write_begin_slow，slow path先调用allocate_budget申请budget，然后再申请页缓存
- 如果allocate_budget成功，vfs将用户数据就copy到page cache中，然后进入write_end
write_end阶段主要做1件事：更新page和inode标记。详细流程如下:
- 如果write_begin因为优化原因没有更新缓存页，在write_end中更新缓存页
- 如果发现脏页，设置page dirty标记
- 如果发现appending，设置inode dirty标记
- 然后vfs后台进程调度将page cache提交到 writeback queue， 然后通过pdflush线程调用ubifs_writepage
writepage阶段主要做3件事： 查找存储位置，更新wbuf，更新TNC。先写索引信息，再写数据信息。写入flash在commit流程中完成。
write_inode流程如下：
1. 按如下顺序查找存储位置（make_reservation）：
1.1. 如果当前的write buf剩余空间满足大小，如果空间足够直接返回；
1.2. 查找LPT内存节点
1.3. 触发垃圾回收（ubifs_garbage_collect，不是回收所有垃圾，只需要会受到符合要求的LEB即可）
1.4. 同步write buf（ubifs_wbuf_sync_nolock）
1.5. 将找到的leb作为bud 写入对于的refnode 以便commit的时候能找到这个bud
1.6. 更新wbuf中的leb为新的leb（ubifs_wbuf_seek_nolock）
1.7. 触发提交流程（do_commit）
2. 更新wbuf（write_head）。如果wbuf刚好满，将wbuf写入flash，并清空wbuf；如果node大小大于wbuf有效部分，先把wbuf填满并将wubf写入flash，剩余部分中将整page大小部分字节写入flash，不满整页的写入wbuf中。如果设置sync标志，同步wbuf数据到flash，并清空wbuf（ubifs_wbuf_sync_nolock）
3. 更新TNC（ubifs_tnc_add）。从TNC中查找匹配key（inode->i_ino）的znode，在叶子节点层查找指定key的znode节点，如果key值精确匹配，返回该节点对应分支在父节点分支数组中的序号；如果key值不是精确匹配，返回父节点中最接近的分支号；返回-1 说明key值太小 在树的最左边不管最终有没有找到匹配key的znode。并将从根到找到的znode这条路径上的索引znode都会被设置为脏（lookup_level0_dirty）；如果znode不在TNC中，从flash中读取，并添加到TNC的页节点中；如果在TNC中找到，则将此页节点设置为脏，并找到LPT中此页节点对应的LEB所在路径上的所有LPT节点设置为脏。
do_writepage流程如下：
1. 将ubifs_data_node的data进行压缩（ubifs_compress）
2. 查找存储位置（make_reservation），同write_inode 步骤1
3. 更新wbuf（write_node），同write_head步骤2，但没有ubifs_wbuf_sync_nolock这一步
4. 更新TNC（ubifs_tnc_add），data 的key为（inode->i_ino, block）组合。同write_head步骤3
4. ubifs commit流程
多种场景下都可以触发commit流程，比如后台进程定时触发。commit的主要作用就是将内存中的大量数据对象刷新到flash中。为了减少commit过程中对系统的影响，commit分为2阶段：start阶段和end阶段。start阶段负责刷新前准备，比如收集需要刷新的内存数据、查找存储位置，更新节点属性等；end阶段负责写flash和内存数据更新。第二阶段的commit可以和文件系统正常操作同步进行。
start commit阶段：
- 将inode wbuf、data wbuf、gc wbuf同步到flash（ubifs_wbuf_sync）
- ubifs_gc_start_commit
- ubifs_log_start_commit：将各c->jheads[i].wbuf中的位置信息更新到内存对象树ubifs_bud，并写入log区
- ubifs_tnc_start_commit：找出tnc中所有脏节点，加入c->cnext链表，为需要写入的znode分配leb，在leb上安排zonde的位置，更新znode的leb等属性，更新lpt属性
- ubifs_lpt_start_commit：对LPT区进行垃圾回收，找出LPT中所有脏节点，加入c->lpt_cnext链表，更新c->ltab表数据，分配LPT 区LEB（alloc_lpt_leb）
- ubifs_orphan_start_commit
- ubifs_get_lp_stats：获取lprops统计信息，以便在更新master node时使用
end commit阶段：
- ubifs_tnc_end_commit：根据c->cnext znode链表构造flash对象ubifs_idx_node，并将index node集合写入main区，释放或标记c->cnext上所有znode
- ubifs_lpt_end_commit：更加ltab，lsave，nnode, pnode对象，构造UBIFS_LPT_LTAB，UBIFS_LPT_LSAVE，UBIFS_LPT_NNODE，UBIFS_LPT_PNODE LPT节点，并写入flash LPT区
- ubifs_orphan_end_commit
- ubifs_log_end_commit：更新log tail lnum（ltail_lnum）等信息
- 更新mst_node并写入flash master区
- ubifs_log_post_commit：释放已提交到main区的ubifs_bud内存对象，并回收其相应的log区空间
- ubifs_gc_end_commit
- ubifs_lpt_post_commit：回收LPT区置垃圾回收标记的LEB块
5. 设计决策及性能优化手段总结
为了提高ubifs读写速度，ubifs采用了缓存、压缩和异地更新手段，这给ubifs的设计上引入了巨大的复杂性。
首先不同的缓存数据对象，有不同的缓存结构、写入策略、提交策略。
然后缓存、压缩和异地更新，又导致缓存数据实际占有的flash物理空间无法准确计算，给查找存储位置带来复杂性。
其次异地更新和数据的细分处理，导致存储对象和存储单元需要细分，给管理存储对象和存储单元带来复杂性。
6. 参考资料
linux kernel 2.6.32
—— 完 ——