一、文件系统
提到文件系统，Linux的老江湖们对这个概念当然不会陌生，然而刚接触Linux的新手们就会被这个概念弄得晕头转向，恰好我当年正好属于后者。
从windows下转到Linux的童鞋听到最多的应该是fat32和ntfs(在windows 2000之后所出现的一种新型的日志文件系统)，那个年代经常听到说“我要把C盘格式化成ntfs格式，D盘格式化成fat32格式”。
一到Linux下，很多入门Linux的书籍中当牵扯到文件系统这个术语时，二话不说，不管三七二十一就给出了下面这个图，然后逐一解释一下每个目录是拿来干啥的、里面会放什么类型的文件就完事儿了，弄得初学者经常“丈二和尚摸不着头脑”。
本文的目的就是和大家分享一下我当初是如何学习Linux文件系统的，也算是一个“老”油条的一些心得吧。
“文件系统”的主语是“文件”，那么文件系统的意思就是“用于管理文件的(管理)系统”，在大多数操作系统的教材里，“文件是数据的集合”这个基本观点是一致的，而这些数据最终都是存储在存储介质里，如硬盘、光盘、U盘等。
另一方面，用户在管理数据时也是文件为基本单位，他们所关心的问题是：
- 我的文件在什么地方放着？
- 我如何将数据写入某个文件？
- 如何从文件里将数据读出来？
- 不再需要的文件怎么将其删除？
简而言之，文件系统就是一套用于定义文件的命名和组织数据的规范，其根本目的是便于对文件进行查询和存取。
- 文件命名：文件系统规定了如何为文件命名，例如文件名的格式、长度、是否区分大小写等规则。比如在 Windows 中，文件名可能会限制字符的使用，而在 Linux 中，文件名则通常不区分大小写。
- 数据组织：文件系统还定义了如何将数据存储在存储设备中，包括如何将文件分成小块、如何管理这些块等。比如，文件可以按块（block）分散存储在硬盘上，文件系统会确保每个块的位置和存取顺序，从而实现文件的完整性。
- 查询与存取：文件系统的一个重要作用是提供高效的查询和存取机制，确保用户能够方便地查找文件、修改内容或删除文件。例如，当你通过文件名打开一个文件时，文件系统会查找该文件在磁盘上的位置，并将文件内容载入内存。
二、虚拟文件系统VFS
在Linux早期设计阶段，操作系统与文件系统是紧密结合的，每种文件系统都需要操作系统特别为其设计的支持代码。这意味着，如果你想在系统中支持多种文件系统（比如ext3、FAT32等），每种文件系统都需要在操作系统中有专门的支持。如果你的系统只支持ext3文件系统，那么其他文件系统（比如FAT32格式的U盘）将无法被识别和使用。
为了支持不同种类的文件系统，Linux引入了虚拟文件系统（VFS）的概念。
VFS最早是由Sun公司提出的，其基本思想是将不同的文件系统（ext3、FAT32、NTFS等）的实现细节屏蔽掉，统一成一个标准化的接口。这使得操作系统能够支持多种文件系统，而不需要关心它们的具体实现细节。
对用户的应用程序而言，VFS为用户提供的是统一的文件操作（如读取、写入文件）接口。这些操作都不关心具体的文件系统是什么类型（比如ext3、FAT32、NTFS）。无论底层文件系统使用什么格式，VFS都会进行适配，确保文件的操作方式对上层应用和用户来说是一致的，用户完全不需要知道底层实现的细节。
三、ext2文件系统
虚拟文件系统VFS是对各种文件系统的一个抽象层，抽取其共性，以便对外提供统一管理接口，便于内核对不同种类的文件系统进行管理。那么首先我们得看一下对于一个具体的文件系统，我们该关注重点在哪里。
对于存储设备(以硬盘为例)上的数据，可分为两部分：
- 用户数据：存储用户实际数据的部分；
- 管理数据：用于管理这些数据的部分，这部分我们通常叫它元数据(metadata)。
我们今天要讨论的就是这些元数据。
在正式展开之前，首先需要明确一个重要概念——块设备（Block Device）。
块设备是指以块（block）为基本读写单位的设备，支持缓冲和随机访问。在构建文件系统时，每种文件系统都会提供相应的 mkfs.xx 工具，允许用户指定块大小（block size），如果不指定，则会使用默认值。
在前面的文章中，我们提到过扇区（Sector）的概念，硬盘的每个扇区512字节，而多个相邻的若干扇区就构成了一个簇，从文件系统的角度看这个簇对应的就是我们这里所说块。
用户在上层系统写入的数据，首先会被缓存在块设备的缓存（内核缓冲区）中。当缓存中的数据填满一个块后，才会被传输给硬盘驱动程序，最终写入存储介质。如果希望立即将设备缓存中的数据写入存储介质，可以使用 sync 命令强制刷新缓存。
一般而言，块越大，存储性能越好，但可能会导致空间浪费；块越小，空间利用率更高，但性能可能有所下降。因此，如果不是专业用户，建议在格式化存储设备时，直接使用默认的块大小。
可以通过以下命令查看存储设备上文件系统使用的块大小：
该命令已经暴露了文件系统的很多信息，接下我们将详细分析它们。
下图是我的虚拟机的情况，三块IDE的硬盘。容量分别是：
- hda: 37580963840/(102410241024)=35GB
- hdb: 8589934592/(102410241024)=8GB
- hdd: 8589934592/(102410241024)=8GB
如果这是三块实际的物理硬盘的话，厂家所标称的容量就分别是37.5GB、8.5GB和8.5GB。可能有些童鞋觉得虚拟机有点“假”，那么我就来看看两个实际的硬盘到底是个啥样子。
西部数据500GB SATA接口硬盘，实际容量是 500107862016B，也就是大约 465.7GB。
希捷160GB SCSI接口硬盘，实际容量是 160041885696B，约为 149GB。
大家可以看到，VMware公司的水平还是相当不错的，虚拟硬盘和物理硬盘“根本”看不出差别，毕竟属于云平台基础架构支撑者的风云人物嘛。
以硬盘/dev/hdd1为例，它是我新增的一块新盘，格式化成ext2后，根目录下只有一个lost+found目录，让我们来看一下它的布局情况，以此来开始我们的文件系统之旅。
对于使用了ext2文件系统的分区来说，有一个叫superblock的数据结构，它包含了文件系统的整体结构信息。这个数据结构对于文件系统的正常运行是至关重要的，操作系统每次访问文件系统时都会首先读取superblock以了解文件系统的状态和布局。
superblock这个数据结构的大小为1024字节，其实ext3的superblock也是1024字节。下面的小程序可以证明这一点：
那么superblock这个数据结构位于分区的哪个位置了？
硬盘是由一个个字节（byte）组成的，每个字节都可以存储8位（1字节）数据。硬盘的第一个字节是从0开始编号，所以第一个字节是byte0，以此类推。
分区头部的1024个字节（byte0~byte1023）并没有存储文件系统的具体数据，而是通常被用来做一些初始化或保留区域。例如，如果该分区不是主引导分区（即不是启动用的分区），那么这1024个字节会被填充为0。
接下来的byte1024到byte2047的1024个字节用于存储superblock。
我们用dd命令把superblock的信息提取出来：
$ dd if=/dev/hdd1 of=./hdd1sb bs=1024 skip=1 count=1
#if=/dev/hdd1：指定输入文件，即 /dev/hdd1，表示从 /dev/hdd1 分区中读取数据。
# of=./hdd1sb：指定输出文件，即 hdd1sb，用于保存读取到的 superblock 数据。
# bs=1024：每次读取 1024 字节的数据。
# skip=1：跳过 1 个 1024 字节的块，即跳过从 byte0 到 byte1023 这一部分（前 1024 字节）。
# count=1：仅读取 1 个 1024 字节的块，即 byte1024 ~ byte2047，这正是 superblock 所在的位置。
上述命令将从/dev/hdd1分区的byte1024处开始，提取1024个字节的数据存储到当前目录下的hdd1sb文件里，该文件里就存储了我们superblock的所有信息。
上面的程序稍加改造，我们就可以以更直观的方式看到superblock的输出了：
可以看出，superblock 的作用就是记录文件系统的类型、block大小、block总数、inode大小、inode总数、group的总数等信息。
对于ext2/ext3文件系统来说数字签名Magic signature都是0xef53，如果不是那么它一定不是ext2/ext3文件系统。这里我们可以看到，我们的/dev/hdd1确实是ext2文件系统类型。
这个示例中hdd1中一共包含1048576个inode节点(inode编号从1开始)，每个inode节点大小为128字节，所有inode消耗的存储空间是1048576×128=128MB；总共包含2097065个block，每个block大小为4096字节，每32768个block组成一个group，所以一共有2097065/32768=63.99，即64个group(group编号从0开始，即Group0～Group63)。所以整个/dev/hdd1被划分成了64个group，详情如下：
用命令tune2fs可以验证我们之前的分析：
再通过命令dumpe2fs /dev/hdd1的输出，可以得到我们关注如下部分：
接下来以Group0为例，主superblock在Group0的block0里，根据前面的分析，我们可以画出主superblock在block0中的位置如下：
因为superblock是如此之重要，一旦它出错你的整个系统就玩儿完了，所以文件系统中会存在磁盘的多个不同位置会存在主superblock的备份副本，一旦系统出问题后还可以通过备份的superblock对文件系统进行修复。
第一版ext2文件系统的实现里，每个Group里都存在一份superblock的副本，然而这样做的负面效果也是相当明显，那就是严重降低了磁盘的空间利用率。所以在后续ext2的实现代码中，选择用于备份superblock的Group组号的原则是3的N次方、5的N次方、7的N次方其中N=0,1,2,3…。根据这个公式我们来计算一下/dev/hdd1中备份有supeblock的Group号：
也就是说Group1、3、5、7、9、25、27、49里都保存有superblock的拷贝，如下：
用block号分别除以32768就得到了备份superblock的Group号，和我们在上面看到的结果一致。我们来看一下/dev/hdd1中Group和block的关系：
从上图中我们可以清晰地看出在使用了ext2文件系统的分区上，包含有主superblock的Group、备份superblock的Group以及没有备份superblock的Group的布局情况。存储了superblock的Group中有一个组描述符(Group descriptors)紧跟在superblock所在的block后面，占一个block大小；同时还有个Reserved GDT跟在组描述符的后面。
Reserved GDT的存在主要是支持ext2文件系统的resize功能，它有自己的inode和data block，这样一来如果文件系统动态增大，Reserved GDT就正好可以腾出一部分空间让Group descriptor向下扩展。
四、一些概念
下面我们来认识一下superblock，inode，block，group，group descriptor，block bitmap，inode table这些家伙。为什么前面不详细介绍这些概念呢，因为任何关于文件系统的文章还是书籍一开始都是先说概念、说理论，让人一直有种雾里看花的感觉。
纸上得来终觉浅，事必躬亲才印象深，所以在前文中我们以一块实际硬盘为例来向大家展示了一下文件系统在存储介质上的布局情况，先让大家对其有个比较直观的认识，然后再逐一对它们进行解释和说明，印象会更深刻些。咱不否认理论的重要性，秉承着“理论指导实践，以实践加深对理论的认识”的宗旨来一步一步入文件系统的乐园。
1、superblock
这个东西确实很重要，前面我们已经见识过。为此，文件系统还特意精挑细选的找了N多后备Group，在这些Group中都存有superblock的副本，你就知道它有多重要了。
说白了，superblock 的作用就是记录文件系统的类型、block大小、block总数、inode大小、inode总数、group的总数等等。
2、group descriptors
千万不要以为这就是一个组描述符，看到descriptor后面加了个s就知道这是N多描述符的集合。确实，这是文件系统中所有group的描述符所构成的一个数组，它的结构定义在include/linux/ext2_fs.h中：
面的程序可以帮助了解一下/dev/hdd1中所有group的descriptor的详情：
其中，文件gp0decp是由命令“dd if=/dev/hdd1 of=./gp0decp bs=4096 skip=1 count=1”生成。每个group descriptor里记录了该group中的inode table的起始block号，因为inode table有可能会占用连续的多个block；空闲的block、inode数等等。
3、block bitmap
一个block bitmap占用一个block大小，而block bitmap中每个bit表示一个对应block的占用情况，0表示对应的block为空，为1表示相应的block中存有数据。
前面已经了解了Group0的一些基本信息如下：
在/dev/hdd1中，一个group里最多只能包含8×4096=32768个block，这一点我们已经清楚了。需要格外注意。另外，/dev/hdd1是新挂载的硬盘，格式化成ext2后并没有任何数据，只有一个lost+found目录。
接下来我们用命令“dd if=/dev/hdd1 of=./gp0 bs=4096 count=32768”将Group0里的所有数据提取出来，我们来看一下Group0的block bitmap，如下：
发现block bitmap的前128字节和第129字节的低4位都为1，说明发现Group0中前128×8+4=1028个block，即block0block1027都已被使用了。第129字节的高4位为0，表示block1028block1031四个block是空闲的；第130字节的最低位是1，说明block1032被占用了；从block1033～block32767的block bitmap都是0，所以这些block都是空闲的，和上表输出的结果一致。
4、inode bitmap
在文件系统中每个对象都有一个对应的inode节点(这句话有些不太准确，因为硬链接和它的目标文件共用一个inode)，里存储了一个对象(文件或目录)的信息有权限、所占字节数、创建时间、修改时间、链接数、属主ID、组ID，如果是文件的话还会包含文件内容占用的block总数以及block号。inode是从1编号，这一点不同于block。
和block bitmap类似，innode bitmap的每个比特表示相应的inode是否被使用。Group0的inode bitmap如下：
/dev/hdd1里inode总数为1048576，要被均分到64个Group里，所以每个Group中都包含了16384个inode。要表示每个Group中16384个inode，inode bitmap总共需要使用2048(16384/8)字节。inode bitmap本身就占据了一个block，所以它只用到了该block中的前2048个字节，剩下的2048字节都被填充成1，如上图所示。
我们可以看到Group0中的inode bitmap前两个字节分别是ff和03，说明Group0里的前11个inode已经被使用了。其中前10个inode被ext2预留起来，第11个inode就是lost+found目录，如下：
5、inode table
那么每个Group中的所有inode到底存放在哪里呢？答案就是inode table。它是每个Group中所有inode的聚合地。
因为一个inode占128字节，所以每个Group里的所有inode共占16384×128=2097152字节，总共消耗了512个block。Group的group descriptor里记录了inode table的所占block的起始号，所以就可以唯一确定每个Group里inode table所在的block的起始号和结束号了。inode的结构如下：
这里我们主要关注的其中的数据block指针部分。前12个block指针直接指向了存有数据的block号；第13个block指针所指向的block中存储的并不是数据而是由其他block号，这些block号所对应的block里存储的才是真正的数据，即所谓的两级block指针；第14个block为三级block指针；第15个block为四级block指针。最后效果图如下：
一个block为4096字节，每个块指针4字节，所以一个block里最多可以容纳4096/4=1024个block指针，我们可以计算出一个inode最大能表示的单个文件的最大容量如下：
所以，我们可以得出不同block大小，对单个文件最大容量的影响。假设block大小为X字节，则:
如下表所示：
最后来一张全家福：
五、细聊文件文件访问
我们已经对ext2fs应该有了一个宏观上的认识，但是前文中所介绍的superblock、block、group、group descriptor和ionde等等，它们到底有什么用呢？下面我们简单热个身，来研究一下在一个磁盘分区上如何根据文件的inode号来访问文件的内容？
在我们将某个分区格式化成ext2/ext3文件系统时，block的大小一定是确定的，即使用户没有手工指定，block也会有个缺省值。在分区总大小一定的情况，每个分区所包含的block数也就固定了，通过superblock我么可以知道分区中一共有多个少group以及每个group中所包含的block数。
当我们拿到一个inode号时，首先要确定该inode属于哪个group，即计算出该inode所在的group号，然后在组描述符数组中找到该group的描述信息，进而就可以获取该inode所表示的文件内容了。
我们设计的结构体信息如下：
最终的测试代码如下rd_file_by_inode.c：
进行编译：
我的一块虚拟硬盘/dev/hdd1只有一个分区，格式是ext2挂载在/mnt/ided目录下。该分区里有几个文件，如下所示。
然后我们依次执行如下命令：
根据文件的inode号分别读取/mnt/ided目录下的bzImage(大小bzImage字节)，klinux-2.6.18.tar.gz(大小156992521字节)和VMwareTools-7.8.6-185404.i386.rpm(大小102939982字节)的内容。验证一下我们读取到的文件内容是否正确：
md5sum算出来的摘要一模一样。有些童鞋可能心里犯嘀咕：“MD5摘要加密算法不是早在2005年就已经被山东大学王小云教授的团队破解了，证明是不可靠的么？那么md5sum命令的输出结果会不会是忽悠人呢？”
怀疑才会使人进步和成长。那么下面这个操作肯定100%值得信赖：
我们把源文件和我们通过inode读取到的文件内容，以十六进制形式输出，然后再比较看其是否差异。理论和实际均证明我们的算法是正确的。 虽然文件系统不是这样来根据inode读取文件内容的，但是我们自己通过一番摸索，对文件系统中的各种术语和名词以及它们的作用的认识和掌握又加深了一个层次。
作者丨上善若水
来源丨公众号：码农有道（ID：b497155298）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
)
)
)
)
)
)
)
)
)
(女士埋珠手术))
)
(耳软骨隆鼻太痛苦了前后对比))
)
)
)