嵌入式系统的分区方案非常重要,它在一定程度上决定了系统的稳定性、安全性和灵活性。这篇我们讲讲嵌入式系统的主流分区方案。
一个最简单、最直接的分区方案通常由u-boot、env环境变量、kernel、rootfs依次组成,layout如下:
这种方案的缺点非常明显,不便于系统在线升级的实施,针对系统在线升级的需求,我们应该预留出升级分区。
这种分区方案,将Kernel和Rootfs分别做了A、B两个分区规划,可以分别对Kernel和Rootfs进行在线升级操作,相比第一种方案更加弹性和灵活。
当然,在这个基础上,我们还可以对Rootfs进行更加细致的再分区,比如单独规划出系统应用和数据分区,处于安全性和稳定性的考虑,可以将系统应用分区格式化为只读文件系统类型,将数据分区格式化为可读可写文件系统类型。对于emmc类型的存储设备,其文件系统类型和我们PC用的硬盘是一致的,没有什么区别,然而flash存储设备就要复杂的多了。在闪存与文件系统的介绍中,我们知道,flash存储设备的文件系统是构建于MTD之上的,所以flash底层的分区,就是一个个MTD分区。我们也知道,现在主流的针对flash存储设备(尤其是大于128MB的)文件系统为UBIFS,UBIFS和UBI总是成对出现的,因为UBIFS是构建于UBI之上的,而UBI又是构建于MTD之上的。
UBI的主要功能是wear leveling,所以UBIFS文件系统一个不同于JFFS2文件系统的地方就是它将wear leveling和文件系统分层实现。注意,UBI是针对整个存储空间而不是单个分区进行wear leveling,这大大增加了flash的使用寿命,下图很好的阐释了UBI的wear leveling的功能,我们可以看到Volume 1 和 Volume 2 的wear leveling范围是整个MTD。
另外,UBI还能实现类似LVM的卷管理功能--Volume Management,可以在MTD分区之上创建多个逻辑分区,针对单个卷,可以动态调整卷大小,也可以选择设置为静态卷(read only)。这里要注意的是,U-Boot和env不能放在UBI Volume逻辑分区,需要直接放在MTD分区,通常Kernel也是直接放在MTD分区。
当然,我们也可以和之前一样预留升级分区,另外也可以在一片flash的不同MTD 分区上构建不同的文件系统,例如UBIFS和CRAMFS、JFFS2等可以共存在一片flash上,以充分利用不同文件系统类型的组合优势。
小结
嵌入式系统的分区方案通常会考虑预留升级分区,emmc的文件系统类型与PC的硬盘一致,操作也类似,而针对flash存储设备,主流为UBIFS和UBI的分区方案。
全部0条评论
快来发表一下你的评论吧 !