ubifs扩展性分析

　　文件系统的可扩展性，主要考察flash规模变大时对文件系统性能的影响，主要考察指标有：

• mount时间
• 访问时间
• 检查修复时间
• 最大文件大小
• 最大文件系统大小
• 最大文件个数

 

mount时间

          相较jffs2需要扫描全部flash，ubifs利用log+bud日志结构，log区大小和bud大小通过DEFAULT_MAX_JNL（32M)的限制，将mount时间复杂度控制在O(1)，时间大为缩短。ubifs mount流程请参照《ubifs性能优化分析》相关小节。但是需要注意的是ubi attach时间复杂度是O(n)，与flash大小成线性关系，是主要的时间瓶颈，这个问题可以通过ubi的fastmap feature（2.6.32内核上还是experiential feature）得到解决。

 

访问时间

          访问时间的可扩展性在2个方面：存储位置的查找更新和存储对象的查找更新，分别介绍如下：

          采用LPT B+ 树按使用情况组织管理逻辑块，其查找和更新时间复杂度为O(logmN），

          采用list管理全free或dirty的逻辑块，其查找时间复杂度进一步优化为O(1)，

          采用heap管理部分free或dirty的逻辑块，其更新时间复杂度为O(longN)，查找时间复杂度进一步优化为O(1)，

          采用TNC B+ 树按索引管理组织逻辑块，文件位置查找和更新时间复杂度为O(logmN）

综上所述，ubifs的访问时间复杂度为O(logmN）。

 

检查修复时间

          ubifs在mount时自动完成检查修复，各区的检查修复手段如下：

          superblock区：大小固定，只占用1个逻辑块，且只读的，理论上不会损坏。只检查，但不修复；时间复杂度为O(1)；

          master区：大小固定，只占用2个逻辑块；A，B2区内容相互备份，进行检查修复；时间复杂度为O(1)。

          log区：为了便于快速检查是否存在重复的（lnum, offs）bud信息或者快速找到指定lnum的bud，bud采用有序rb tree组织，其index为lnum，其查找和更新时间复杂度为O(logN），而且log+bud日志结构通过DEFAULT_MAX_JNL（32M)的上限限制，即N具有上限。

          LPT区：无修复动作。因为lprops与逻辑块成线性关系，其检查时间复杂度也为O(n)，为了不影响mount时间，所以检查功能（dbg_check_lprops）也默认关闭。

          orphan区：orphan区本身无修复检查。但是对于unclean umount，会利用orphan区删除孤儿节点。因为orphan区的逻辑块个数固定（为1或2个），所以存于orphan区的孤儿节点的个数固定，其遍历的时间复杂度为O(1)。

          main区：检查因为有log+bud的日志保护，所以ubifs不检查扫描main区下的index tree。

综上所述，ubifs的检查修复时间复杂度为O(1)。

 

最大文件大小

          ubifs本身无限制，受限于文件系统大小等其他限制

 

最大文件系统大小

          取决于block的个数限制(int block_cnt)和大小限制（#define UBIFS_BLOCK_SIZE  4096），最大2^32 * 4K = 16T

 

最大文件个数

          取决于inode的限制。最多支持2^32 个文件(#define MAX_INUM 0xFFFFFFFF)

 

--EOF--