linux文件系统 - 初始化

Posted 2020-10-24 AlanTu

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了linux文件系统 - 初始化相关的知识，希望对你有一定的参考价值。

加载initrd(上)

一、目的

本文主要讲述linux3.10文件系统初始化过程的第二阶段：加载initrd。

initrd是一个临时文件系统，由bootload负责加载到内存中，里面包含了基本的可执行程序和驱动程序。在linux初始化的初级阶段，它提供了一个基本的运行环境。当成功加载磁盘文件系统后，系统将切换到磁盘文件系统并卸载initrd。

如果是嵌入式设备，那么最终的文件系统就是initrd。

二、cpio文件格式

initrd常用的的文件格式是cpio，cpio格式记录了文件系统的结构和内容。

cpio格式具体定义如图1所示：

cpio格式的文件由段组成，最后一个段比较特殊，文件名为”TRAILER!!!”。

每个段都由文件头、文件名和文件体组成；文件名和文件体的长度由文件头中的name_len和body_len指定，并且文件名和文件体需要按指定字节对齐，所以尾部包含padding。

文件头共110个字节，头6个字节固定为070701，剩下字节的含义分别为：索引节点号、文件模式、用户id、组id、链接数、时间戳、文件体长度、主设备号、次设备号、设备号、文件名长度、保留字段。

其他详细情况请参见init/initramfs.c文件，这里不再描述。

图1

三、initrd文件实例

为了更直观的理解cpio格式的initrd文件，下面看一个实例。

在ubuntu环境中，boot目录下存放着经过压缩的cpio格式文件initrd。

将boot目录下的initrd文件拷贝到任意目录下，重名为为initrd.gz，并且使用gunzip解压。

这样我们就得到了一个cpio格式的initrd文件，使用vi查看文件内容如图2所示(由于文件太大，只展示了部分内容)：

简单分析后显示该文件包含了script/nfs-top目录、script/nfs-top/ORDER文件、script/nfs-top/udev文件、run目录、标志cpio结束的TRAILER!!!文件。

图2

四、解压initrd文件

initrd经过gunzip解压后，可以使用cpio工具解压cpio格式的文件。命令如下:

root: cpio-idmv < initrd

解压成功后，使用ls命令查看initrd文件内容如图3所示：

bin和sbin目录下包含基本的可执行程序；conf和etc目录下是配置文件；lib目录下是可执行程序使用的动态库；scripts目录下是脚本程序；init程序。initrd必须提供一个init程序，linux在加载完initrd后，会跳转到init程序，由init程序负责后面的初始化工作。

图3

五、总结

本文详细介绍了cpio格式的initrd文件，以及解压后各个目录的含义。initrd文件系统提供了init程序，在linux初始化阶段的后期会跳转到init程序，由该程序负责加载驱动程序和挂载磁盘文件系统以及其他的初始化工作。

加载initrd(中)

一、目的

上文详细介绍了CPIO格式的initrd文件，本文从源代码角度分析加载并解析initrd文件的过程。

initrd文件和linux内核一般存储在磁盘空间中，在系统启动阶段由bootload负责把磁盘上的内核和initrd加载到指定的内存空间中；然后，再由内核读取和解析initrd文件，在VFS(目前只有rootfs的根目录)中新建目录、常规文件、符号链接文件以及特殊文件；这样VFS就从根目录"/"成长为一棵枝繁叶茂的大树了。

二、函数调用过程

initrd详细的加载过程在init/initramfs.c中实现的，为了更好的理解加载过程，我们给出了关键函数的调用关系图1。这里需要注意下，由于使用roofs_initcall()宏在initcallroofs段中注册了populate_rootfs()函数，因此在执行do_initcalls()函数时会隐示调用populate_rootfs()。

图1

三、initcall简介

linux在代码段中定义了一个特殊的段initcall，该段中存放的都是函数指针；linux初始化阶段调用do_initcalls()依次执行该段的函数。关于该段的详细信息可以参见vmlinux.lds.S链接脚本。

用户可以调用以下一组宏在initcall段中注册函数指针；initcall段分为initcall0-initcall7这8个等级，initcall0段的优先级最高，initcall7段的优先级最低，优先级高的段最先被执行；initcallrootfs段优先级介于5和6之间。

#define __define_initcall(fn, id) \\
179     static initcall_t __initcall_##fn##id __used \\
180     __attribute__((__section__(".initcall" #id ".init"))) = fn

187 #define early_initcall(fn)          __define_initcall(fn, early)
      
196 #define pure_initcall(fn)           __define_initcall(fn, 0)
        
198 #define core_initcall(fn)           __define_initcall(fn, 1)
199 #define core_initcall_sync(fn)      __define_initcall(fn, 1s)
200 #define postcore_initcall(fn)       __define_initcall(fn, 2)
201 #define postcore_initcall_sync(fn)  __define_initcall(fn, 2s)
202 #define arch_initcall(fn)           __define_initcall(fn, 3)
203 #define arch_initcall_sync(fn)      __define_initcall(fn, 3s)
204 #define subsys_initcall(fn)         __define_initcall(fn, 4)
205 #define subsys_initcall_sync(fn)    __define_initcall(fn, 4s)
206 #define fs_initcall(fn)             __define_initcall(fn, 5)
207 #define fs_initcall_sync(fn)        __define_initcall(fn, 5s)
208 #define rootfs_initcall(fn)         __define_initcall(fn, rootfs)
209 #define device_initcall(fn)         __define_initcall(fn, 6)
210 #define device_initcall_sync(fn)    __define_initcall(fn, 6s)
211 #define late_initcall(fn)           __define_initcall(fn, 7)
212 #define late_initcall_sync(fn)      __define_initcall(fn, 7s)

用户使用不同优先级的initcall宏可以很方便的在linux代码中注册函数指针；将这些函数指针存储在相应的initcall段中；最终，由do_initcalls()按照优先级依次执行段中的函数，具体的代码实现如下：

715 static initcall_t *initcall_levels[] __initdata = {
716     __initcall0_start,
717     __initcall1_start,
718     __initcall2_start,
719     __initcall3_start,
720     __initcall4_start,
721     __initcall5_start,
722     __initcall6_start,
723     __initcall7_start,
724     __initcall_end,
725 };

678 int __init_or_module do_one_initcall(initcall_t fn)
679 {
681     int ret;
686     ret = fn();
    }

739 static void __init do_initcall_level(int level)
740 {
742     initcall_t *fn;
            ... 
751     for (fn = initcall_levels[level]; fn < initcall_levels[level+1]; fn++)
752         do_one_initcall(*fn);
753 }
754 
755 static void __init do_initcalls(void)
756 {
757     int level;
758 
759     for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
760         do_initcall_level(level);
761 }

回到加载initrd这个话题中，在init/initram.c的最后使用rootfs_initcall宏注册了populate_rootfs()函数；基于以上分析，我们知道这里就是加载initrd文件的入口，下面就开始分析该函数的功能。

627 rootfs_initcall(populate_rootfs);

四、加载initrd文件

系统启动阶段，bootload将initrd加载到内存起始地址为initrd_start，结束地址为initrd_end的内存中。

populate_rootfs()调用unpack_to_rootfs()从内存中读取并解析initrd文件；根据CPIO的格式我们知道initrd文件是由很多个段组成，且段中又是由文件头、文件名和文件体组成，因此该解析程序可以使用了状态机原理处理initrd文件。

解析程序定义了以下8种状态：Start(初始状态)、Collect(获取符号链接文件信息状态)、GotHeader(获取文件头信息状态)、SkipIt(跳过该段状态)、GotName(获取文件名并新建文件状态)、CopyFile(写文件状态)、GotSymlink(新建符号链接文件状态)、Reset(终止状态)。

376 static __initdata int (*actions[])(void) = {
377     [Start]     = do_start,
378     [Collect]   = do_collect,
379     [GotHeader] = do_header,
380     [SkipIt]    = do_skip,
381     [GotName]   = do_name,
382     [CopyFile]  = do_copy,
383     [GotSymlink]    = do_symlink,
384     [Reset]     = do_reset,
385 };

为了直观理解initrd文件的解析过程，下面给出状态机跳转图2。

从图中可以看出将文件分为符号链接和非符号链接两种情况处理，这是因为符号链接文件是一种特殊的文件，只有第一个符号链接文件的inode存储的是真实数据，而其他符号链接文件inode中存储的是第一个符号链接文件的路径名，因此需要把第一个符号链接文件的路径名缓存起来，缓存的数据结构是hash表，所以在处理符号链接文件时多了一些hash表的操作，因此分为了符号链接文件和非符号链接文件这两种情况来处理。

initrd文件的详细解析过程如下：

1、S0：初始状态，初始化一些全局变量；

2、S1：获取符号链接文件的文件头和文件体；

3、S2：根据CPIO格式的定义，获取文件头信息；

4、S3：跳过当前CPIO格式的段，继续处理下一个段；

5、S4：获取文件名，并在VFS中新建文件；

6、S5：将文件内容写入到新建文件中；

7、S6：新建符号链接文件；

8、S7：处理完当前CPIO格式的段，继续一个段的处理。

从图中还可以看出，由于目录文件和特殊文件没有文件内容，因此跳过了S5状态，直接进入S3状态。

图2

五、总结

通过以上分析，程序就可以成功解析initrd文件，并使用sys_dir()、sys_open()、sys_mknod()、sys_symlink()等系统调用新建目录、常规文件、特殊文件和符号链接文件了。此时，VFS从只有根目录"/"成长为了一棵内容丰富的大树。

加载initrd(下)

一、目的

linux把文件分为常规文件、目录文件、软链接文件、硬链接文件、特殊文件(设备文件、管道文件、socket文件等)几种类型，分别对应不同的新建函数sys_open()、sys_mkdir()、sys_symlink()、sys_link()、sys_mknod()。

系统初始化阶段成功加载initrd后，调用这些接口函数创建各种文件，因此这些函数在linux文件系统初始化过程中起到了重要作用，本文将详细描述这些接口函数的实现过程。

这些接口函数主要在fs/namei.c、fs/open.c文件中实现，可以在这两个文件中找到对应的源代码。

二、快速路径查找

在以上系统调用的实现中，需要解决一个关键问题：如何根据待新建文件的路径名，快速找到父目录的位置。得到父目录的位置后，才能创建待新建文件的目录，以及分配inode节点。

例如：新建/tmp/test.txt文件，首先需要根据”/tmp/test.txt”路径名查找到test.txt父目录tmp在VFS中的位置，然后基于tmp的位置才能为test.txt文件新建目录及分配inode节点。

由于快速路径查找使用比较频繁，所以对查找效率要求较高，否则会影响系统性能。do_path_lookup(intdfs, const char *name, unsigned int flags, struct nameidata*nd)函数负责实现该功能，其中name参数是路径名，nd参数是structnameidata结构体，nd的path成员记录了父目录的位置，last成员记录了待新建文件的文件名。例如：path记录了tmp在VFS中的位置，last记录”test.txt”文件名。

该函数的实现比较复杂，不方便对照源代码讲述，因此下面重点描述了该函数的主要操作。但是为了读者方便阅读源代码，给出如下关键函数的调用关系：do_path_lookup()->path_lookupat()->path_init()->link_path_walk()->walk_component()->lookup_fast()->__d_look_rcu()->__follow_mount_rcu()

do_path_lookup()在实现过程中，按照以下三种情形来操作：

1、路径名在单文件系统中：从根目录或当前目录开始，根据目录拓扑结构，递归查找父目录；

2、路径名在多文件系统中：在递归查找时，需要从当前文件系统的挂载点切换到最终文件系统的目录拓扑结构中，然后继续查找；

3、路径名在挂载点重复挂载多文件系统的情况：在递归查找时，需要从当前文件系统的挂载点切换到最终文件系统的目录拓扑结构中，然后继续查找；

为了理解以上三种情形的具体差异，举例说明：待新建文件路径名为”/usr/tmp/log/new.txt”。

情形1：

如下图所示，路径名只在单个文件系统ext3中存在，所以根据目录拓扑结构，递归查找父目录即可；查找完成后，使用nd.path记录父目录log的位置，nd.last记录了字符串常量”new.txt”。

情形2：

在情形2中，路径名横跨了两个文件系统，minix挂载在ext3的tmp目录上；当成功挂载minix后，设置挂载点tmp为已挂载状态，并且将tmp指向minix文件系统。

路径查找程序根据路径名”/usr/tmp/log/new.txt”查找到tmp目录时，发现tmp为已挂载状态，所以从挂载点tmp切换到minix根目录；然后，确认minix根目录不是已挂载状态后，在minix文件系统中继续查找剩下的路径名”log/new.txt”；查找完成后，使用nd记录查找结果。

情形3：

在情形3中，ext3的tmp目录重复挂载了两个文件系统minix和nfs；当成功挂载minix后，设置挂载点tmp为已挂载状态；当在同一挂载点tmp挂载nfs时，发现tmp已经是挂载状态，所以从挂载点tmp切换到minix根目录，在该根目录挂载nfs文件系统，并且将minix根目录设置为已挂载状态。linux支持在同一挂载点挂载多个文件系统的操作，但是只有最后被挂载的文件系统才是可见的，所以使用ls命令只能看到nfs文件系统的内容。

路径查找程序根据路径名”/usr/tmp/log/new.txt”查找到tmp目录时，发现tmp为已挂载状态，所以从挂载点tmp切换到minix根目录；然后发现minix根目录也是已挂载状态，所以继续切换到nfs根目录；最后，确认nfs根目录不是已挂载状态后，在nfs文件系统中继续查找剩下的路径名”log/new.txt”；查找完成后，使用nd记录查找结果。