文件系统的可扩展性，主要考察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--