• ubi层次


    转:http://www.360doc.com/content/11/0518/13/496343_117643185.shtml

    UBI是什么?

    它是一种flash管理方式

    flash是一系列连续的物理擦除块组成的。

    UBI卷是一系列连续的逻辑擦除块(eraseblock),每一块都可以被映射到物理分区,这种映射是由UBI管理的。

    UBI是靠什么来管理这些物理擦除块的呢??

    首先要区分一些层次:
    1.MTD subsystem :
    provide ubiform interface to access flash (e.g. /dev/mtd0)
    2.UBI subsystem 
    UBI works on top of MTD devices ,provide a notion of UBI volumes
    3.UBIFS file system
    work on top of UBI volume

    UBI header

    UBI在每一个物理擦除块的开始有2个64-byte的ubi-headers
    1.erase counter header (or EC header);
    记录着物理可擦除块上erase counter(擦除次数),以及其他一些不那么重要的信息
    Erase counter是指物理可擦除块被擦除的次数
    2.volume identifier header (or VID header)
    记录着卷号(volume ID)和 这个物理可擦除块所属的逻辑可擦除块的ID
    所有的UBI headers被CRC-32校验和所保护着
    在我们sep4020的nandflash中,每一页为512字节,一个物理擦除块的大小为16K,也就是32页
    其中EC header在每一个擦除块的第一页上(所以offset为0)
    VID header在每一个擦除块的第二页上(偏移量offset为512)
    所以一个完整的物理擦除块是什么结构呢?
    第一页保存EC头,占了64字节(浪费了好多哦)
    第二页保存VID头,同样也占64字节
    其余的十页用来保存数据
    Volume table

    卷表(volume tabel)是一种flash上的数据结构,包含了UBI设备上的每一卷(volume)的信息(基本信息),卷表是一系列 volume table record,每一个记录块上包含了一下的信息:

    1.volume size
    2.volume name 
    3.volume type (dynamic or static )
    4.volume alignment
    5.update marker(防止数据更新发生意外打断,可以恢复)
    6.auto-resize flags
    7.CRC-32 校验和

    UBI内部保持着两份卷表volume table,保持UBI的稳定性,防止突然断电的情况
    这两份卷表保存在一个叫做layout volume的内部卷区中,这个卷区对于用户空间是不可见的

    怎么才能从一个逻辑ID找到与它映射的物理ID?
    其实在我们的volume是有三个表的
    1.volume table     (flash media)
    2.eraseblock association (EBA) table    (ram)
    3.erase counters (EC) table (ram)
    建立EBA和EC table就必须扫描整个ubi设备,来获得物理块与逻辑块之间映射关系的全部信息
    在这个映射关系变更时,要及时的更新表
    UN_MAP:
    unmap就是清除物理块(peb)和逻辑块(leb)这种映射关系

    那么这种映射关系不存在的话,那么物理块中保持的数据也就没有意思了,所以需要清除(erase),这种清除工作是后台进程来执行的

    unmap机制通常被当做是一种快速擦除nand的手段

    1.不需要等待返回,因为总是存在一些unmaped的物理块peb可供来进行映射(ubi策略上保留了一些物理块)

    均衡损耗:
    如果老是对着同一个nandflash的物理块进行擦除、读写操作,就坏导致这个物理块成为一个坏块。

    UBI中擦除会连同保存了UBI的物理与逻辑映射关系的VID header一同擦除
    但是EC header是保留的

    这样每一次擦除都会断开物理块(P1)与逻辑块之间(L1)的映射关系,假如我现在向逻辑块L1中写数据,系统会根据EC头中擦除次数去找一个物理块,然后建立映射关系。
    这样就避免了对同一个物理块操作次数过多

    在建立逻辑块与物理块的映射时,ubi会从所以得未进行映射的物理块中找出一个擦除次数最少的建立映射关系

    下面看一下挂载一个ubifs文件系统的步骤:
    ubiattach /dev/ubi_ctrl -m 3                                      
    1.ubiattach是将一个mtd分区关联为ubi设备,在这个过程中,会再次扫描mtd分区(全部扫描)
    2.建立EBA 和EC table
    3.接下来系统会去读ubi中保存的两个卷表,显然第一次的时候这两个卷表是不存在的。
    4.ubi会去创建两个卷表,然后初始化之。一般是我们mtd设备的前两个擦除块
    (leb0 和 leb1)
    5.接下来会创建一个后台进程,然后唤醒它,这个进程干什么的呢?它会进行物理块擦除的工作

    创建卷:
    ubimkvol /dev/ubi0 -N ubifs -s 15MiB 
    在ubi函数是调用了ubi_create_volume
    前面我们讲一个mtd设备关联为ubi设备,在一个mtd设备中可以创建好多的volume
    在创建一个volume的同时,要将volume table中对应位进行更新

    挂载:
    mount -t ubifs ubi0:ubifs /mnt

    次数(yaffs) 读速度(block2到sdram) 写速度(sdram到block2)
    1                           11.59s                               50.67s
    2                           10.79s                               50.65s
    3                           11.10s                               50.09s
    平均                      11.16s(1.245MB/S)            50.47s(282.02KB/S)
    次数(ubifs)       读速度                                写速度
    1                              9.26s                               33.95s
    2                                7.44s                              32.87s
    3                                7.80s                              34.06s
    平均                          8.17s(1.7MB/S)          33.63s(423.24KB/S)

  • 相关阅读:
    Linux文件查找
    Linux之正则表达式
    linux文本处理
    Linux压缩归档管理
    spring-security问题记录
    mybatis-plus&springboot
    Mysql8- Public Key Retrieval is not allowed
    MySQL 5.7安装(linux)
    git把本地代码上传(更新)到github上
    linux相关(find/grep/awk/sed/rpm)
  • 原文地址:https://www.cnblogs.com/pengdonglin137/p/3398697.html
Copyright © 2020-2023  润新知