鸿蒙（HarmonyOS）开发知识@IT·互联网

鸿蒙内核源码分析(挂载目录篇) | 为何文件系统需要挂载

2025-06-03  本文已影响0人  迪士尼在逃程序员

关于文件系统的介绍已经写了三篇,但才刚刚开始,其中的 [文件系统篇] 一定要阅读,用生活中的场景去解释计算机各模块设计的原理和运行机制是整个系列篇最大的特点,计算机文件系统相关概念是非常的多的,若不还原其本质,不跳出这些概念去看问题是很难理解它为什么要弄这么些东东出来让你头大. 反之,如果搞明白了这些概念背后的真相你想忘记它们都很难,问题是经不起追问的, 多追问几个为什么就会离本源越来越近.

前几篇中追问了以下几个问题:

如果想明白了这些问题, 就能逆向倒推为什么要有目录,为什么需要挂载使用, 为什么需要根文件系统.一切将是水到渠成 .
先说目录,从内核视角看目录可不能像普通老百姓从用户视角去看,目录是为了屏蔽文件系统之间的差异而设计出来的概念,也就说必须在inode的局部唯一性之上存在一个全局唯一性才能解决统一性问题.目录从更大尺度上去兼容并蓄各文件系统.

那它是如何解决的呢?

    ├─古龙系列 inode id : 789
    │  ├─小李飞刀 inode id : 56
    │  ├─楚留香 inode id : 342
    │  └─陆小凤 inode id : 432
    └─金庸系列 inode id : 5567
        ├─倚天屠龙记 inode id : 89
        ├─射雕英雄传 inode id : 1212
        └─笑傲江湖 inode id : 567843

B文件系统内部如下:

    ├─席绢系列  : inode id : 87 
    │  ├─上错花轿嫁对郎 : inode id : 89 
    │  ├─吻上你的心 : inode id : 789 
    │  └─红袖招 : inode id : 56 
    └─琼瑶系列 : inode id : 321 
        ├─在水一方 : inode id : 234 
        ├─梅花三弄 : inode id : 5678 
        ├─烟雨濛濛 : inode id : 987 
        └─还珠格格 : inode id : 23

其中789,89两个文件系统中都用到了,但它们在内部是唯一的.在A文件系统中通过 789 就能找到 56,342,432,并且能得到相对路径: 古龙系列/小李飞刀,古龙系列/楚留香 .也就是说拿着inode只要进入了本文件系统地盘,那都不叫事,事都能给你办的妥妥的. 那如何才能进入而且不会搞错呢?

挂载目录

答案就是: 挂载目录,也叫挂载点,集体统一指挥的前提是需要先回归集体.如果已经有一颗目录树,将你们的目录树挂上来形成一颗更大的树不就统一了吗? 例如已有:

├─小说系列 inode id : 2
│  ├─武侠小说 inode id : 13
│  ├─言情小说 inode id : 14

其实它也是个文件系统,叫根文件系统, 它的 inode也是独立的, 并且能得到相对路径 小说系列/武侠小说,小说系列/武侠小说
通过两个 mount动作, 将它变成如下所示

├─小说系列 (根文件系统)
    ├─武侠小说 (根文件系统)
    │  ├─古龙系列 (A文件系统)
    │  │  ├─小李飞刀
    │  │  ├─楚留香
    │  │  └─陆小凤
    │  └─金庸系列 (A文件系统)
    │      ├─倚天屠龙记
    │      ├─射雕英雄传
    │      └─笑傲江湖
    └─言情小说 (根文件系统)
        ├─席绢系列 (B文件系统)
        │  ├─上错花轿嫁对郎
        │  ├─吻上你的心
        │  └─红袖招
        └─琼瑶系列 (B文件系统)
            ├─在水一方
            ├─梅花三弄
            ├─烟雨濛濛
            └─还珠格格

哦,原来整颗目录树是由这三个文件系统像搭积木一样拼接起来.而两个文件系统的衔接点,必然会产生一个新的概念出来, 这个概念就是 挂载点,也叫 挂载目录

Mount

可以猜测到的是挂载点的描述结构体中必有两个文件系统接驳点inode的信息,挂钩和脱钩的操作也只属于它专有.具体如下:

//挂载操作
struct MountOps {
    int (*Mount)(struct Mount *mount, struct Vnode *vnode, const void *data);//挂载
    int (*Unmount)(struct Mount *mount, struct Vnode **blkdriver);//卸载
    int (*Statfs)(struct Mount *mount, struct statfs *sbp);//统计文件系统的信息，如该文件系统类型、总大小、可用大小等信息
};
struct Mount {
    LIST_ENTRY mountList;              /* mount list */          //通过本节点将Mount挂到全局Mount链表上
    const struct MountOps *ops;        /* operations of mount */ //挂载操作函数   
    struct Vnode *vnodeBeCovered;      /* vnode we mounted on */ //要被挂载的节点 即 /bin1/vs/sd 对应的 vnode节点
    struct Vnode *vnodeCovered;        /* syncer vnode */        //要挂载的节点   即/dev/mmcblk0p0 对应的 vnode节点
    LIST_HEAD vnodeList;               /* list of vnodes */     //链表表头
    int vnodeSize;                     /* size of vnode list */ //节点数量
    LIST_HEAD activeVnodeList;         /* list of active vnodes */  //激活的节点链表
    int activeVnodeSize;               /* szie of active vnodes list *///激活的节点数量
    void *data;                        /* private data */   //私有数据,可使用这个成员作为一个指向它们自己内部数据的指针
    uint32_t hashseed;                 /* Random seed for vfs hash */ //vfs 哈希随机种子
    unsigned long mountFlags;          /* Flags for mount */    //挂载标签
    char pathName[PATH_MAX];           /* path name of mount point */   //挂载点路径名称  /bin1/vs/sd
    char devName[PATH_MAX];            /* path name of dev point */     //设备名称 /dev/mmcblk0p0
};

解读

    // 文件系统 proc 对 MountOps 接口实现
    const struct MountOps procfs_operations = {
        .Mount = VfsProcfsMount,//装载
        .Unmount = NULL,
        .Statfs = VfsProcfsStatfs,//统计信息
    };
    //文件系统 fat 对MountOps 接口实现
    struct MountOps fatfs_mops = {
        .Mount = fatfs_mount,
        .Unmount = fatfs_umount,
        .Statfs = fatfs_statfs,
    };
    //文件系统 jffs 对MountOps 接口实现
    const struct MountOps jffs_operations = {
      .Mount = VfsJffs2Bind,
      .Unmount = VfsJffs2Unbind,
      .Statfs = VfsJffs2Statfs,
    };

问题

上面提到 挂载就需要一个已经存在的文件系统提供目录,也就是根文件系统,但根文件系统又是怎么来的呢?

写在最后

上一篇 下一篇

猜你喜欢

热点阅读