鸿蒙内核源码分析(挂载目录篇) | 为何文件系统需要挂载 | 百篇博客分析OpenHarmony源码 | v65.01

百篇博客系列篇.本篇为:
v65.xx 鸿蒙内核源码分析(挂载目录篇) | 为何文件系统需要挂载 | 51.c.h.o
文件系统相关篇为:
- v62.xx 鸿蒙内核源码分析(文件概念篇) | 为什么说一切皆是文件 | 51.c.h.o
- v63.xx 鸿蒙内核源码分析(文件系统篇) | 用图书管理说文件系统 | 51.c.h.o
- v64.xx 鸿蒙内核源码分析(索引节点篇) | 谁是文件系统最重要的概念 | 51.c.h.o
- v65.xx 鸿蒙内核源码分析(挂载目录篇) | 为何文件系统需要挂载 | 51.c.h.o
- v66.xx 鸿蒙内核源码分析(根文件系统) | 先挂到
/上的文件系统 | 51.c.h.o - v67.xx 鸿蒙内核源码分析(字符设备篇) | 字节为单位读写的设备 | 51.c.h.o
- v68.xx 鸿蒙内核源码分析(VFS篇) | 文件系统和谐共处的基础 | 51.c.h.o
- v69.xx 鸿蒙内核源码分析(文件句柄篇) | 深挖应用操作文件的细节 | 51.c.h.o
关于文件系统的介绍已经写了三篇,但才刚刚开始,其中的 文件系统篇 一定要阅读,用生活中的场景去解释计算机各模块设计的原理和运行机制是整个系列篇最大的特点,计算机文件系统相关概念是非常的多的,若不还原其本质,不跳出这些概念去看问题是很难理解它为什么要弄这么些东东出来让你头大. 反之,如果搞明白了这些概念背后的真相你想忘记它们都很难,问题是经不起追问的, 多追问几个为什么就会离本源越来越近.
前几篇中追问了以下几个问题:
- 对内核来说
inode真的是唯一的吗? 答案是否定的,使用电脑的经验告诉我们,当把电脑硬盘拆下来挂到其他电脑上时,里面的数据一样能访问,并没有让你一切重来,而inode是存放硬盘上的,你没有办法让已编好序号的inode按你的逻辑重排,这不合理更不科学. 所以结论是inode的全局唯一性不是不想做,而是压根臣妾做不到啊.inode唯一性仅限于某个文件系统的内部. - 经验还告诉我们硬盘可以有多个分区,每个分区可以被格式化成不同的文件系统.(例如:C盘:
NTF,D盘FAT32,E盘ext),数据可以相互拷贝,毫无障碍.不同的文件系统是如何实现文件迁移到呢 ? 具体实现细节是怎样的 ?
如果想明白了这些问题, 就能逆向倒推为什么要有目录,为什么需要挂载使用, 为什么需要根文件系统.一切将是水到渠成 .
先说目录,从内核视角看目录可不能像普通老百姓从用户视角去看,目录是为了屏蔽文件系统之间的差异而设计出来的概念,也就说必须在inode的局部唯一性之上存在一个全局唯一性才能解决统一性问题.目录从更大尺度上去兼容并蓄各文件系统.
那它是如何解决的呢?
- 首先各个文件系统记录了自己内部目录层级关系的,这个在 文件系统篇 | 目录项 中已经说过了. 这种关系是绝对的但也是相对的,绝对是对内,相对是对外. 例如:
A文件系统内部如下:├─古龙系列 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
};
解读
mountList: 挂载点由双向链表全局统一管理vnodeBeCovered:,记录挂到根文件系统的哪个节点上.vnodeCovered: 设备也是一种文件,也被统一管理,统一在/dev目录下,内核会给设备的每个分区分配一个vnode节点,一个分区对应一个文件系统,设备文件后续有专门的介绍,此处不展开.vnodeList: 指的是A/B文件系统的节点链表,由挂载点结构体记录.activeVnodeList:A文件系统节点的使用情况,统一由双向链表管理.activeVnodeSize:A文件系统已被使用的节点数data这是文件系统的私有数据,跟 索引节点篇 | Vnode -> data一样理解.pathName:这个很重要,记录了小说系列/武侠小说,因为文件的绝对路径是拼接起来的,以小说系列/武侠小说/古龙系列/小李飞刀这个完整的路径来说,它是由小说系列/武侠小说(根文件系统提供) +古龙系列/小李飞刀(A文件系统提供) 这两部分拼成的.devName:一般名称类似于mmcblk0p0=mmc+block0+Partition0mmc:MultiMediaCard可理解为硬盘block0: 0号块设备Partition:0号分区,一个分区上安装一个文件系统.
MountOps ops: 每个文件系统挂载方式是不用的,都需要实现这几个接口(挂载,卸载,统计).// 文件系统 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,
};
问题
上面提到 挂载就需要一个已经存在的文件系统提供目录,也就是根文件系统,但根文件系统又是怎么来的呢?
鸿蒙内核源码分析.总目录
v08.xx 鸿蒙内核源码分析(总目录) | 百万汉字注解 百篇博客分析 | 51.c.h .o
百万汉字注解.百篇博客分析
百万汉字注解 >> 精读鸿蒙源码,中文注解分析, 深挖地基工程,大脑永久记忆,四大码仓每日同步更新< gitee| github| csdn| coding >
百篇博客分析 >> 故事说内核,问答式导读,生活式比喻,表格化说明,图形化展示,主流站点定期更新中< 51cto| csdn| harmony| osc >
关注不迷路.代码即人生

QQ群:790015635 | 入群密码: 666
原创不易,欢迎转载,但请注明出处.
鸿蒙内核源码分析(挂载目录篇) | 为何文件系统需要挂载 | 百篇博客分析OpenHarmony源码 | v65.01的更多相关文章
- 鸿蒙内核源码分析(管道文件篇) | 如何降低数据流动成本 | 百篇博客分析OpenHarmony源码 | v70.01
百篇博客系列篇.本篇为: v70.xx 鸿蒙内核源码分析(管道文件篇) | 如何降低数据流动成本 | 51.c.h.o 文件系统相关篇为: v62.xx 鸿蒙内核源码分析(文件概念篇) | 为什么说一 ...
- 鸿蒙内核源码分析(文件句柄篇) | 深挖应用操作文件的细节 | 百篇博客分析OpenHarmony源码 | v69.01
百篇博客系列篇.本篇为: v69.xx 鸿蒙内核源码分析(文件句柄篇) | 深挖应用操作文件的细节 | 51.c.h.o 文件系统相关篇为: v62.xx 鸿蒙内核源码分析(文件概念篇) | 为什么说 ...
- 鸿蒙内核源码分析(VFS篇) | 文件系统和谐共处的基础 | 百篇博客分析OpenHarmony源码 | v68.01
子曰:"质胜文则野,文胜质则史.文质彬彬,然后君子." <论语>:雍也篇 百篇博客系列篇.本篇为: v68.xx 鸿蒙内核源码分析(VFS篇) | 文件系统和谐共处的基 ...
- 鸿蒙内核源码分析(字符设备篇) | 字节为单位读写的设备 | 百篇博客分析OpenHarmony源码 | v67.01
百篇博客系列篇.本篇为: v67.xx 鸿蒙内核源码分析(字符设备篇) | 字节为单位读写的设备 | 51.c.h.o 文件系统相关篇为: v62.xx 鸿蒙内核源码分析(文件概念篇) | 为什么说一 ...
- 鸿蒙内核源码分析(根文件系统) | 先挂到`/`上的文件系统 | 百篇博客分析OpenHarmony源码 | v66.01
百篇博客系列篇.本篇为: v66.xx 鸿蒙内核源码分析(根文件系统) | 先挂到/上的文件系统 | 51.c.h.o 文件系统相关篇为: v62.xx 鸿蒙内核源码分析(文件概念篇) | 为什么说一 ...
- 鸿蒙内核源码分析(索引节点篇) | 谁是文件系统最重要的概念 | 百篇博客分析OpenHarmony源码 | v64.01
百篇博客系列篇.本篇为: v64.xx 鸿蒙内核源码分析(索引节点篇) | 谁是文件系统最重要的概念 | 51.c.h.o 文件系统相关篇为: v62.xx 鸿蒙内核源码分析(文件概念篇) | 为什么 ...
- 鸿蒙内核源码分析(文件系统篇) | 用图书管理说文件系统 | 百篇博客分析OpenHarmony源码 | v63.01
百篇博客系列篇.本篇为: v63.xx 鸿蒙内核源码分析(文件系统篇) | 用图书管理说文件系统 | 51.c.h.o 文件系统相关篇为: v62.xx 鸿蒙内核源码分析(文件概念篇) | 为什么说一 ...
- 鸿蒙内核源码分析(文件概念篇) | 为什么说一切皆是文件 | 百篇博客分析OpenHarmony源码 | v62.01
百篇博客系列篇.本篇为: v62.xx 鸿蒙内核源码分析(文件概念篇) | 为什么说一切皆是文件 | 51.c.h.o 本篇开始说文件系统,它是内核五大模块之一,甚至有Linux的设计哲学是" ...
- 鸿蒙源码分析系列(总目录) | 百万汉字注解 百篇博客分析 | 深入挖透OpenHarmony源码 | v8.23
百篇博客系列篇.本篇为: v08.xx 鸿蒙内核源码分析(总目录) | 百万汉字注解 百篇博客分析 | 51.c.h .o 百篇博客.往期回顾 在给OpenHarmony内核源码加注过程中,整理出以下 ...
随机推荐
- ES6中新增的数组知识记录
JSON数组格式转换 let json = { '0': 'hello', '1': 'I am ', '2': 'michael', length:3 } 这就是一个JSON数组格式,跟普通的JSO ...
- asp.net core 搭建WebAPI微服务-----cosnul服务
参考网址:https://blog.csdn.net/weixin_42084199/article/details/108643555 在此之前需要准备的是: vs2019,以往版本不支持dotne ...
- WPF三维立体效果3D
并不是真的3D,类似游戏的2.5D. 先上效果图. 变形一下也可以 起先我是想,把这种绘图啊啥的,都做成控件,给别人直接用就行了.但是做的过程中发现. 要做简单易用的控件,实在是花时间. 而且花的时 ...
- 什么是挂载,Linux挂载详解
前面讲过,Linux 系统中"一切皆文件",所有文件都放置在以根目录为树根的树形目录结构中.在 Linux 看来,任何硬件设备也都是文件,它们各有自己的一套文件系统(文件目录结构) ...
- python下 conda命令手册
0.说明: 对于tensorflow配合keras使用,因为linux服务器没有root权限,所以目前最高可用版本是 1.6.0,否则就会报错某些 so找不到 conda install -n xu ...
- PE文件结构(32/64差异)
1 基本概念 下表描述了贯穿于本文中的一些概念: 名称 描述 地址 是"虚拟地址"而不是"物理地址".为什么不是"物理地址"呢?因为数据在内 ...
- JDBC中级篇(MYSQL)——处理大文本(CLOB)
注意:其中的JdbcUtil是我自定义的连接工具类:代码例子链接: package b_blob_clob; import java.io.FileNotFoundException; import ...
- springboot使用redis(从配置到实战)
概述 springboot通常整合redis,采用的是RedisTemplate的形式,除了这种形式以外,还有另外一种形式去整合,即采用spring支持的注解进行访问缓存. 准备工作 pom.xml ...
- mybaits源码分析--缓存模块(六)
一.缓存模块 MyBatis作为一个强大的持久层框架,缓存是其必不可少的功能之一,Mybatis中的缓存分为一级缓存和二级缓存.但本质上是一样的,都是使用Cache接口实现的.缓存位于 org.apa ...
- Android系统编程入门系列之应用内键值对数据的简单保存
在应用程序间及与用户的通信交互过程中,会产生并传递一系列数据.针对这些数据,有部分是只在应用程序中使用的缓存数据,还有一部分是在不同位置多次或长时间使用的持久化数据. 对于缓存数据来说,通常以代码中定 ...