0. 文件系统和图书馆

在linux上操作文件，和在图书馆借书是非常相似的。
硬盘上的文件系统，好比图书馆的书架；而vfs则是图书馆的管理系统。

oracle创建分区索引？内核的工作：
1. 维护一个文件的目录树（dentry），供用户查找自己想要的文件。
2. 维护每个进程打开的文件(files_struct, file)，以及整个系统打开的文件。
3. 维护文件系统，包括：书架(block group), 书（block） , 书的索引信息（inode）。

1. 基本概念

文件系统采用两级索引，我们都知道，磁盘是存储文件用的，但是磁盘必须先格式化为某种格式的文件系统，才能存储文件。

文件系统的目的就是组织和管理磁盘中的文件。

上图展示了在ext2文件系统下，磁盘的存储空间是如何被组织的。
为了理解上图，我们先了解一些基本概念。

1.1 块（block)

hdfs路径、磁盘中最小存储单元是扇区（1扇区=512Bytes），而文件系统的最小存储单元是Block（一般地，1Block = 4KB = 8 扇区）。在 Ext2 文件系统中，磁盘的整个空间是以块为单位被管理的，块也是被分配来存储数据的最小单位，一个文件即使只有 1 字节，也会至少占用一个存储块。类似于内存中使用地址标记每个字节，文件系统用存储块的块号来标记每个存储块。

扇区大小在磁盘出厂就已经定了，而Block大小是在格式化时决定的。例如， mke2fs -b 4096 /dev/sda6 在格式化 /dev/sda6时指定了Block大小为4096Bytes。

在 Ext2 文件系统中，可选的块大小有 1 KB、2 KB 或 4 KB，系统管理员可以根据磁盘中存储的文件的特点选择不同的块大小，如果要存储的文件大多数是几 KB 的小文件，那么选择 1 KB 的块尺寸能提高磁盘存储空间的利用率；而如果系统中大多数的文件都比较大，那么就应该选择更大的块大小，这样一方面可以提高读写效率，另一方面也可以减少需要的索引节点数量。

1.2 块组(block group)

Ext2 文件系统把把属于同一个文件的数据块存放在同一块组中，块组可有效地提高文件连续性。

如果用一所学校来类比整个磁盘，那么学校中的每个教室就类比于一个存储块组，教室里的每一个座位就对应一个磁盘存储块；座位和教室都会被按顺序编号，从一个座位的编号，就可以计算出它所在的教室，以及在第几排第几列。

1.3 元数据

要完成持久化地存储文件数据的功能，文件系统除了要保存文件的数据之外，还需要保存一些元数据，用于记录每块数据存放在何处，磁盘中已用的和空闲的存储空间有哪些，以及文件的访问属性、访问时间等；另外，文件系统还需要记录被指定的块大小、索引节点数量等信息。文件系统的设计核心就在于如何组织这些信息。

1.4 位图（bitmap)

位图的数据结构很单纯，就是一连串的比特位，每个位标记一个目标对象的当前状态。在文件系统中，比特 0 表示空闲，1 表示被占用。被位图标记的对象一般都大小固定并且连续存储，所以根据比特位的位置就可以计算出被标记对象的存储位置。

2. 块组结构

2.1 索引节点（inode）

索引节点的大名相信很多人都听说过，每个索引节点的标记对象是一个广义的文件。

索引节点里面存储的信息都是普通用户经常用到的。比如，ls 命令的输出中，文件的大小、访问权限、属主、修改时间等， 以及一个文件占用的所有的存储块也是在索引节点中被记录的。

我们可以知道的是，如果能够找到文件的 inode 的话，那么自然就会知道这个文件所放置数据的 block 号码， 当然也就能够读出该文件的实际数据了。

2.2 索引位图–标记inode的使用状态

索引节点的使用状态是用索引位图标记的，为了使用位图结构，索引节点的大小需要是固定的，所有的索引节点依次保存在 N 个连续的存储块内。

在 Ext2 文件系统中，索引节点的大小是 128 字节，一个 4 KB 的存储块可以容纳 32 个索引节点。如果我们为每个存储块都预留一个索引节点的话，那么一个 128 M 的块组就需要 32 KB 个索引节点，也就是需要 1 KB 个存储块，所以，整个磁盘存储空间的 3% 左右需要预留出来给索引节点使用。

但是一般的系统中不会所有的文件都是几 KB 的小文件，所以索引节点通常不需要预留这么多。大多数 Linux 发行版的默认的存储块大小是 4 KB，每 4 个存储块预留一个索引节点，那么索引节点占用的磁盘存储空间比例就可以降低到 0.8% 左右。

后期的 Ext4 文件系统中，随着文件属性的扩展，每个索引节点的大小增大了一倍，达到了 256 字节，那么索引节点占用的存储空间比例就变成了 1.56%。这就是很多文章中提到的索引节点会占用大约 1% 的磁盘存储空间的由来。

2.3 数据位图–标记block的使用状态

数据位图的标记对象是当前块组内的每个存储块。一个块组中存储块的数量是由数据位图的标记范围来确定的。

拿 256 GB 的存储空间为例，如果使用默认 4 KB 的存储块大小，那么一个数据位图块可以有 8 * 4 K = 32 K个比特，可以标记 32 KB 个存储块。所以，Ext2 文件系统就会把每 32 KB 个存储块划分为一个块组，每个块组的总容量为 32 KB * 4 KB = 128 MB，整个 256 GB 的存储空间会被分成大约 2048 个块组。

2.4 组描述符

每个块组的开始部分都是超级块与组描述符，它们之中记录的是整个文件系统的信息。

在 Ext2 文件系统中，超级块和组描述符虽然在每个块组里面都有一份数据，但是实际上内核只使用第 0 块，其他块组中的数据被用作第 0 块数据的备份，用于在异常状态下磁盘状态的检查和恢复。

超级块SuperBlock中会存储整个文件系统的类型、大小，文件系统中索引节点的总数量，当前文件系统的空间占用量、空闲块数量，存储块的大小，文件系统的最近一次检查时间等信息。

组描述符GDT，Group Descriptor Table中会包含每个块组的总体信息，如数据位图的块号、索引节点位图的块号、索引节点表的起始块号、空闲数据块和 inode 的个数等。

每个组描述符会占用 32 字节的空间，所以，上面实例中，2048 个块组一共需要 2048 * 32 = 64 KB 的空间来存储所有的组描述符，也就是会占用 16 个存储块。

3. 可靠性（日志功能）

在 Ext2 文件系统中，如果遭遇突然断电，系统重启之后需要遍历整个磁盘来执行一致性检查和恢复。

这在硬盘容量比较小的过去还不是什么太大问题，即使遍历整理磁盘，通常可以在几分钟内完成。但是当磁盘容量变得越来越大时，问题开始变得越来越严重，现在动辄以几百 GB 计的硬盘，完成整个磁盘的检查通常需要几个小时的时间。这对高可用服务器和生产环境服务器都是完全不可接受的。

所以，我们需要一种机制，在不需要遍历整个磁盘的情况下也能确保磁盘中数据的一致性。

Linux 的 Ext3 文件系统实现了日志记录功能，它的实现思路来源于数据库技术，其基本思想是，在系统对文件系统执行任何元数据更新之前，先把要执行的操作日志记录到文件系统一块专用的日志分区内，当元数据更新完成之后，再从日志记录分区内移除该条操作记录。

这样，当系统重启时，只需要使用该日志分区内的信息就足以把磁盘数据恢复到一个一致的状态：

如果日志分区中没有任何记录，说明系统上次停止运行时没有中途打断任何文件系统更新操作，磁盘一定是处在一致状态的；
如果日志分区中有操作记录，那根据记录内容重新更新一次磁盘就可以了。
引入日志功能之后，磁盘的每次一致性检查最多也不过几秒钟。

但是，需要知道的是，日志功能保证的只是文件系统中元数据的一致性，但是并不能保证数据的完整性。也就是说，如果系统断电的时候正在写入一个体积很大的文件，那么重启之后这个文件可能会丢掉一些数据。虽然 Ext3 文件系统也可以配置为把每次写操作的数据计入日志内，以保证数据的一致性，但是这会导致非常大的性能损失，所以并不常用。

4. 参考

https://gitbook.cn/gitchat/column/5bfbbe9b7d496f13396961de

简直不要太硬了！一文带你彻底理解文件系统