sundayhut's Blog

创建软链接： ln -s 被指向的文件  软连接文件

创建硬链接： 上述指令去掉-s

删除软连接：  rm -rf qtool/    说明：相对路径qtool是一个软连接，删除qtool下面的东西。但是保留qtool文件。

                      rm -rf qtool  说明，文件qtool以及底下的东西一起删除

原则，所有的指令都是要在exc退出后的模式才能使用；

u -- 回退，理解为windows的ctrl+z

w -- 往下查找，一直按右键移到一行的某个位置很慢，可以用w来加速

5、w -- 先按5，再按w，往后挑5个，这个在上一条基础上移动更快

b -- 往上查找，与w相反

5、b -- 往下查找，与5、w相反

/core -- 按n查找下一个，按N查找前一个

yy、 p -- 复制当前的行

3yy、p -- 复制当前开始后的3行

dd -- 删除当前行

EXT4 design

Ext3系统已有许实用的缺省状态，有良好的兼容性，可靠性。

Ext4更支持大的文件系统，对大文件支持性更好。

磁盘上的一些结构变了：纳秒级时间戳、extent分配、预分配

写在磁盘崩溃也可以保证可靠性

64bit的JBD

向前兼容文件系统/文件系统可升级

多块分配

延迟分配

第一配额指标的支持 1st Class Quota Support

大的块分配 Large allocation blocks

EXT4 Extents

extent对应的是磁盘上和逻辑上都连续的空间，Extents的设计使得更少的元数据管理更多的数据，所以可以做到更快的访问。

Extents在磁盘上的数据结构

/*extent bottom of the tree 的结构*/

/*extent 除开bottom of the tree 的结构*/

struct ext4_extent_idx {

        __le32  ei_block;       /* index covers logical blocks from 'block' */

        __le32  ei_leaf_lo;     /* pointer to the physical block of the next *

                                 * level. leaf or next index could be there */

        __le16  ei_leaf_hi;     /* high 16 bits of physical block */

        __u16   ei_unused;

};

四篇文章链接

FOSS.in 2006 ext4 paper

OLS 2005 ext3 presentation

OLS 2005 ext3 paper

Ext3 for large filesystems

本文为https://ext4.wiki.kernel.org/index.php/Ext4_Design的翻译

Frequently asked questions

Ext2、ext3、ext4的关系

三个文件系统可以归为一类文件系统，有很好的前后兼容性，如Mkfs成ext3文件系统，在挂载时可以挂在成ext2，ext4的形式。但是ext4的文件系统，不能挂载成ext2、ext3的形式。Ext3要求有日志，但是ext2中没有日志。Ext4文件系统可以使用无日志的模式mount

Why创造ext2

Minx文件系统bug：filename只能在14自符内。Minix支持的最大的file大小为64Mib,而ext文件系统支持2Gb的文件大小，filename可以到256个字符。但是ext2和minix一样只有一个上次更改的时间戳，上次访问时间，上次inode更改时间。它使用链表的形式存储空闲块，这意味着更容易I形成碎片。在1993，ext2文件系统更新版本后，新版本可以支持最大4T的文件大小，增加了可移植的时间戳接口。而且文件系统可扩展，所以可以在文件系统中加入新特性。

文件系统的特点：

EXT2:

哈希索引目录：(EXT2_FEATURE_COMPAT_DIR_INDEX) 

扩展属性块(EXT2_FEATURE_COMPAT_EXT_ATTR)

File type in directory entries (EXT2_FEATURE_INCOMPAT_FILETYPE) 

减少块组描述符的备份(EXT2_FEATURE_INCOMPAT_META_BG)

减少超级块的备份(EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER)

文件可以大于2GB(EXT2_FEATURE_RO_COMPAT_LARGE_FILE)

EXT3

扩展属性块、更大的inode结点 (EXT3_FEATURE_COMPAT_EXT_ATTR)

在线文件系统大小更改(EXT3_FEATURE_COMPAT_RESIZE_INODE)

目录项hash索引 (EXT3_FEATURE_COMPAT_DIR_INDEX)

日志file(EXT3_FEATURE_COMPAT_HAS_JOURNAL) 注意：ext3必须有日志的模式，对比ext4

File type in directory entries(EXT3_FEATURE_INCOMPAT_FILETYPE)

日志的恢复(EXT3_FEATURE_INCOMPAT_RECOVER)

减少块组描述符的备份(EXT3_FEATURE_INCOMPAT_META_BG)

减少超级块的备份(EXT3_FEATURE_RO_COMPAT_SPARSE_SUPER)

文件可以大于2GB(EXT3_FEATURE_RO_COMPAT_LARGE_FILE)

EXT4

扩展属性块、更大的inode(EXT3_FEATURE_COMPAT_EXT_ATTR)

在线文件系统大小更改(EXT3_FEATURE_COMPAT_RESIZE_INODE)

目录项hash索引(EXT3_FEATURE_COMPAT_DIR_INDEX)

日志file(EXT3_FEATURE_COMPAT_HAS_JOURNAL)注意ext4可以以没有日志的形式挂载

File type in directory entries(EXT3_FEATURE_INCOMPAT_FILETYPE)

日志的恢复 (EXT3_FEATURE_INCOMPAT_RECOVER)

文件可以以extents形式分配空间(EXT4_FEATURE_INCOMPAT_EXTENTS)

支持大于2^32个文件块(EXT4_FEATURE_INCOMPAT_64BIT)

灵活的块组Flexible block group(EXT4_FEATURE_INCOMPAT_FLEX_BG)

减少块组描述符的备份 (EXT3_FEATURE_INCOMPAT_META_BG)

减少超级块的备份(EXT3_FEATURE_RO_COMPAT_SPARSE_SUPER)

文件可以大于2GB(EXT3_FEATURE_RO_COMPAT_LARGE_FILE)

组描述符的校验和稀疏索引表(EXT4_FEATURE_RO_COMPAT_GDT_CSUM)

目录内容可以多于32000个项 (EXT4_FEATURE_RO_COMPAT_DIR_NLINK)

纳秒级别时间戳和创建时间 (EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE)

整个文件大小可以大于2Tb (EXT4_FEATURE_RO_COMPAT_HUGE_FILE)

如何测试EXT4文件系统

测试文件系统和硬件平台最好的方法是系统上真实的应用。Benchmark只是模拟的测试方式，他们不能反映应用的IO负载

现有的测试工具等见： intertubes

Wiki的一个很棒的文章： Comparison of file systems（不同文件系统比较）

Can I undelete files in Ext4?（ext4能否恢复删除文件？）

No, in the same way that the ext3 journal requirements to be consistent after a crash prevent undelete of ext3 files, it isn't possible to undelete ext4 files.

如何把ext2、ext3挂载的系统变为ext4，用到两条指令？

使用tune2fs来使其可以使用ext4特性

# tune2fs -O extents,uninit_bg,huge_file /dev/DEV
# e2fsck -f /dev/DEV

如果在把ext2文件系统mount为ext4类型时，想要其具备日志特性，使用指令：

# tune2fs -j /dev/DEV

若用指令把ext2、ext3文件系统挂载为ext4形式后，以后就不能再挂在成原来的ext2、ext3形式了。

可以使用下列指令使加入日志的ext2文件系统去除日志：

# tune2fs -O ^has_journal /dev/DEV

一些ext4的特性在ext3文件系统中不能体现。

在/proc/fs/jbd2/partition/history中提供的信息

执行cat /proc/fs/jbd2/partition/history 有如下信息

R/C  tid   wait  run   lock  flush log   hndls  block inlog ctime write drop  close

R    7102  0     5000  0     1424  4     68681  5     6   

R    7103  0     5000  0     1644  4     64579  9     10  

R    7104  0     5000  0     856   32    38719  11    12  

R    7105  0     5000  0     1052  0     47142  12    13  

R    7106  0     5000  0     1172  16    56028  11    12  

R    7107  0     5000  0     1416  4     71047  11    12  

R    7108  0     5000  0     1640  4     81125  5     6   

R    7109  0     5000  0     1616  4     77314  6     7   

R    7110  0     5000  0     1640  0     76111  5     6   

:

:

文件的目的是提供ext4日志的。每个当前日志事件的提交就往这个文件中加入一行。每列的含义如下：

R/C

事物在运行或是提交。（注意目前的JBD2只显示正在运行的事物，不显示提交的数据）

Tid

事物的ID，用以区别不同的JBD2事物

Wait

事物开始所等待的毫秒数。如果应用做同步操作或者事物包含块的最大数量。

Lock

事物等待锁住所花的毫秒数

Flush

number of milliseconds flushing blocks to the filesystem for ordered mode before the transaction can be committed

log

将block的数据写入日志所需要的毫秒数

Hndls

日志事物的handles个数

Block

日志事物的block个数

Inlog

这个事物写入到block的block数目，包括日志的额外开销

/proc/fs/jbd2/<partition>/info提供的信息

在cat /proc/fs/jbd2/partition/info提供如下信息：

这个文件中显示了自mount以来，该文件系统在/proc/fs/jbd2/partition/history目录信息下的统计平均信息

如何改变ext4文件系统的大小

ext4在线改变大小的方式和ext3很相似，使用resize2fs或者ext2resize，但是对整个文件系统最大的大小有限制（4TB大小）。在有META_BG标记下这个限制大小可以增大。

什么是bitmap 分配器

Ext2和ext3通过遍历块的比特位来查看块是否空闲。十分低效，ext4的block allocator替代了bitmap allocator实现该功能，所以ext4比ext3也快了许多。

ext3和ext4的主要区别

ext4的新特性在http://sundayhut.is-programmer.com/ 译文中解释过了

jdb和jdb2的区别

两者大体上相同，但是jdb2增加了几个兼容性的功能：

1.    支持64位的文件系统

2.    日志事务的校验

3.    异步的事务提交块写

另外，对于刷新数据jbd2实施了一种新的ordered模式，它与延时分配结合使用，防止了当有大量数据写入文件系统而阻塞日志事物的提交的情况。这也避免了当有一个大的写（heavy write）时，fsync()延迟过长。

能在SSD上使用ext4文件系统吗？

可以，SSD实质上和其他的块设备没有什么区别。在先进的ssd上（主要考虑ssd寿命问题，日志区需要频繁修改），还可以把日志区放在SSD中。参考该链接：you can even put the journal on the SSD as well

链接中提出

1. 可以把ext4作为无日志的模式挂载。此时系统崩溃就要执行fsck来恢复，恢复的速度取决于你文件系统的碎片化程度，由于ssd本身速度较快，可能恢复在10秒内
2. 就算把journal放在ssd中也不会有太大问题，作者自己就是这么干的，估摸着在ssd坏了之前自己早就换电脑了。
3. 自己做了一点小手脚来减少文件系统的写操作。比如说/tmp目录使用tmpfs文件系统、把firefox的缓存放在/tmp目录下。

本文为Frequently Asked Questions的翻译

本文为https://ext4.wiki.kernel.org/index.php/Ext4_Howto的翻译。粗略介绍ext4的特性。

EXT4 特性：

兼容性：

         Ext3文件系统可以以ext4的形式挂载，且不需要改变磁盘的布局格式。但是可以通过在只读模式下运行一些命令让ext3文件系统具备ext4文件系统的一些优势。

文件系统、文件更大：

下面是ext3、ext4文件系统总大小和单个文件大小的最大值

Ext3 16Tb  2Tb

Ext4 1Eb   16Tb

若要支持块数目大于2^32个块的文件，文件系统必须具备extents。因为block map只知道32bit的block号。在e2fsprogs1.42.9中，这个功能由mke2fs使能控制。

子目录扩展

在Ext3中，单个目录下的文件及其目录数目不超过32000个。EXT4将这个限制增大了倍数

Extents

         传统的如ext3，管理一个文件的不同块使用的是block机制，这对于大文件来说是效率很低的，比如大文件的截断、删除操作。Extent就是一系列的连续的block。它的含义是说：数据在接下来连续的n个blocks中，这样就避免了一个一个block的描述。例如：一个100M的文件在传统ext3的方式下需要存放在256000个block中，terrible。现在ext4就可以由几个extents来管理。Extents不仅提高了性能，而且可以改善碎片的情况（extents优先考虑磁盘上连续的布局方式）。

多blocks的分配（主要说malloc）

         当ext3需要将数据写入磁盘时，块分配器会决定分配那个空闲块给要写入的数据。当时ext3的块分配器一次性只会分配一个块，也就是说如果一个100M的文件要写入磁盘，那么快分配器要调用25600次。这不仅十分低效，更可怕的是，由于分配器无法知道一共要分配多少个块，而只是机械的一个个块的分配，所以说无法从磁盘的角度实现磁盘优化分配利用。EXT4使用multiblock allocator(malloc)，这个功能能实现调用一次而分配多个块，从而减小了开销。这提高了性能。尤其是在结合extents和delay allocation策略。这个特性不会影响磁盘的格式特性。此外，ext4的block、inode分配器有其他的优化。

延迟分配

         延迟分配是在XFS,ZFS,btrfs、Reiser 4文件系统中的特性。该策略就是尽可能晚地分配blocks，这点与传统的文件系统（如ext3）相反，ext3的策略是，尽可能早地分配blocks。举一个例子：调用write()，文件系统会立马分配好数据要写如磁盘的地点，即便数据当前在cache中，没有写入磁盘。这种方式有缺陷：比如说，一个进程连续写一个文件，文件缓慢增大，故系统会不断地的给数据分配空间，因为块分配器不知道到底多少够用，所以由于write函数催使而不断分配。而延迟分配机制会延时数据块的分配，在数据从cache被替换出来时，块分配器才会真正分配块写在磁盘中的位置。这样就在预置要分配块的总数的前提下，就能最优化地分配块，使磁盘空间得到最好的利用。延迟分配与前面两种机制结合使用有很好的效果，因为许多文件最终从cache写入磁盘时，会以extents方式，而该方式的blocks是通过malloc，即多blocks分配机制申请得到的。

快速的fsck

         Fsck是一个很慢的操作，尤其在第一步：检查文件系统中所有的节点。在ext4中，在每个group的inode 表后会存储一个未使用inode节点的清单（该清单为了保证安全，有校验信息），所以fsck操作不会去检查inodes，fsck的实验结果表明，根据inode使用数目的不同，fsck时间提高了2到20倍。这里不许注意的是，是fsck，而非ext4，建立的未使用inode节点清单。这就意味着必须运行fsck来建立未使用inode节点清单，下一次运行fsck才会变快（需要运行fsck完成ext3到ext4的转变）。“flexible block groups （灵活的块分组）”也与加速fsck有关系

日志校验和

         日志是磁盘最常用的一部分，所以这一块更容易出现故障。而且一个从损坏日志的恢复行为会导致文件系统的更大损坏。Ext4为日志块的数据做了校验，从而可以知道日志块是否损坏。日志校验还有一个附加好处：它使得ext3这种两阶段的日志提交系统，变成了单阶段提交，在一些情况下加速了文件系统的操作，性能提高了20%，所以可靠性和性能都提升。（注意：提高性能的部分：异步log，在缺省默认状态下是关闭的，在稳定性改善后，之后的版本会支持该功能）

“无日志”模式

日志模式虽然提高了文件系统的可靠性，但是存在开销。在ext4中，可以关闭日志模式，性能可以得到一定提升

在线碎片整理

（这个功能正在开发，之后的版本会支持该功能）。虽然延迟分配、extents、多块分配能减少碎片，但是碎片仍然会有。举一个例子：在一个目录里写   了三个文件，这三个文件连续的放在磁盘上。某天，你需要对中间的文件追加写，但中间文件空间不够了，这是，中间文件追加部分就只好碎片化地存在磁盘另一个位置了。（作实验）这样会引起一个seek操作，或者需要把中间文件全部内容再连续的存放在一个空间足够的磁盘位置（这样导致了若一个操作需要读取该目录下三个文件，就需要又一次seek操作）。另外，文件系统只关心特定的碎片，比如说boot相关的的需要连续

Inode相关特征

更大的inode节点：ext3支持可配置的inode节点大小（通过mkfs的 -I 参数），但是inode大小的缺省值128bytes。Ext4文件系统inode大小的缺省值是256bytes。Inode扩展的空间用于存储一些额外的域，如纳秒级时间戳、inode版本等，剩下的空间用来存储ext4的一些扩展属性。这会使得对这些属性的访问变快，对于一些需要用到拓展属性的应用，访问速度会增大3至7倍。

当一个目录创建的时候，inode预留空间会预留几个inode，估计inode会在短时间内被用到，即在目录中创建文件时要用到。这个措施能提高性能，因为在目录中创建新文件时可以直接使用预留的inode。文件的创建、删除都会效率更高

纳秒级的时间戳意味着inode中记录“更改时间”的数据可以使用到纳米级别，而在ext3中问秒级别

持久预分配

这个特征，在ext4最近的版本中实现，由glibc在不支持它的文件系统中仿真，她允许应用预分配磁盘的空间：应用告诉文件系统预分配空间，文件系统预分配必须的blocks以及相关数据结构，但是在应用真正写数据之前磁盘对应区域是没有数据的。对于P2P应用来说，他们需要有他们自己的“预分配机制”，分配的区域用于长达数小时甚至数天的下载，但是如果文件系统本身提供这个接口，那么预分配机制就会更加有效率。这个机制有几个用途：第一：避免P2P应用类程序自己进行低效的预分配，即用zeros来填充一个文件。第二：改善碎片问题，由于块一次性分配，所以会尽可能连续。第三：保证应用一直有其所需的空间，这点对应RT-ish类的应用很重要，若没有预分配，文件系统可能在操作的一般就使用完毕了（full）。这个特点在libc的posix_fallocage()中实现。

缺省状态有Barriers

这是在保证文件系统健全性和提高文件系统性能的权衡（你可以通过mount –o barrier=0,如果你在做benchmarking建议你试试）。LWN的一篇文章所说：文件系统的代码必须保证在写操作提交前，所有事物的信息都被写到了日志中。只是有顺序地进行写操作是不够的。中间层的cache中会有一些驱动器为了提高性能，重新定向IO操作的顺序。所以，文件系统必须在写提交前明确地告诉磁盘拿到所有的日志数据。如果提交请求先写，日志崩溃了，内核的I/O子系统通过barriers使其能恢复正常。Barrier禁止barrie后的写，除非该barrier之前的操作已经提交了。通过barrier，文件系统可以确保磁盘上的结构保持一致性。

转化ext3文件系统到ext4形式

可以将ext3的文件系统mount为ext4的形式，使用ext4的文件系统驱动。这样文件系统就可以使用延时分配，多块分配等。

下面指令从ext2文件系统转化为ext3文件系统（支持日志了）

tune2fs –j /dev/DEV

下面指令使ext3文件系统支持ext4文件系统特征

tune2fs –O extents,uninit_bg,dir_index /dev/DEV

注意的是，该指令一旦运行，文件系统就不能再被mount为ext3的文件系统了

运行上述指令后，必须运行fsck来修整一下磁盘上的结构

e2fsck –Fdc0 /dev/DEV

注意：

运行fsck可能会提示“一个或者多个组描述校验无效”，这个现象时可预见的，这也是为什么tune2fs需要fsck。

通过extents的特性，之后的新文件会以extents形式存在，但是老的文件不会变成extents形式。

如果将跟文件系统转化成ext4形式，你徐璈安装一些ext4可以运行的GRUB版本，启动项可能一开始可以启动，但是内核升级后，就可能不能启动了（按Alt+F+F来检查文件系统）

不建议使用e2fsprogs中的resize2fs来改变inode的大小

如果你在tunefs中去掉omit，你可以跳过fsck步骤。

bio：代表了一个io请求

request：一个request中包含了一个或多个bio，为什么要有request这个结构呢？它存在的目的就是为了进行io的调度。通过request这个辅助结构，我们来给bio进行某种调度方法的排序，从而最大化地提高磁盘访问速度。

request_queue：每个磁盘对应一个request_queue.该队列挂的就是request请求。

具体如下图：(有颜色方框头表示数据结构的名字)

请求到达block层后，通过generic_make_request这个入口函数，在通过调用一系列相关的函数（具体参见我另一篇博客）把bio变成了request。具体的做法如下：如果几个bio要读写的区域是连续的，即积攒成一个request（一个request上挂多个连续的bio，就是我们通常说的“合并bio请求”），如果一个bio跟其他的bio都连不上，那它就自己创建一个新的request，把自己挂在这个request下。当然，合并bio的个数也是有限的，这个可以通过配置文件配置。

对于上段补充一点：上层的一次请求可能跨越了多个扇区，形成不连续的扇区段，那么该请求构造的每个bio对应着一个连续的扇区段。故一个请求可以构造出多个bio。

合并后的request放入每个设备对应的request_queue中。之后设备驱动调用peek_request从request_queue中取出request，进行下一步处理。

这里要注意的是，在实现设备驱动时，厂家可以直接从request_queue中拿出排队好的request，也可以实现自己的bio排队方法，即实现自己的make_request_fn方法，即直接拿文件系统传来的bio来自己进行排队，按需设计，想怎么排就怎么排，像ramdisk,还有很多SSD设备的firmware就是自己排。（这里就和我另一篇博客，说到为什么generic_make_request要设计成一层递归调用联系起来）。

网上有个问答也是我的疑惑：这里我写一遍，加强记忆

bio结构中有bio_vec数组结构，该结构的的数组可以指向不同的page单元，那为什么不在bio这一级就做了bio合并工作，即把多个bio合并成一个bio，何必加入一个request这么麻烦？

答：每个bio有自己的end_bio回调，一旦一个bio结束，就会对自己进行收尾工作，如果合并了，或许有些bio会耽误，灵活性差。

参考博客：

http://blog.csdn.net/flyingcloud_2008/article/details/5818995

http://www.udpwork.com/item/8437.html

扇区：扇区是在磁盘设备中，数据传送的基本单元，即硬件设备数据传送的单元。不允许传送小于一个扇区的数据，但是可以传送几个相邻扇区的数据。

块：块是VFS和文件系统传送数据的基本单元，也是映射层的映射单元。一个块对应着设备上一个或多个相邻的扇区。

页：内存的管理单元

块缓冲区：页中包含一个或多个块缓冲区，每个块缓冲区对应着上述一个块的内容，同一个页的块缓冲区可以不连续。

段：深入理解linux内核一书中描述段是一个内存页或者内存页的一部分，包含相邻磁盘的数据。但我赶脚这么理解不好。分段应该是方便内存的管理，为了满足用户（如程序员狗）在编程和使用方面的需求。引入段有如下好处：

1.方便编程，用户把自己的作业划分为若干个段，每个段都从0编制，有自己的段号和段内偏移。段为二维地址空间，而页为一维。

2信息组织、共享。在程序和数据的共享中，信息是以逻辑单位为基础的，如共享某个函数，分页同的页只存放信息的物理块，无实际意义，不便于共享。而段是有信息的逻辑单位，故方便共享。

3.信息保护。通过段越界等可以保护信息。

关于段页可以参考http://baike.baidu.com/view/3227088.htm

address_space对象是文件系统中关于内存中页高速缓存的核心数据结构。这篇博客以address_space对象为切入点，分析文件系统的页高速缓存。

1背景

在文件系统中，内存中存在着dentry和inode结构，其中其分别的作用可以见我另一篇博客《dentry与inode》。由于这些结构要反复使用，所以内存里开辟了目录项高速缓存以及索引结点高速缓存，提高其访问速度。但这里要提到的是另一种高速缓存：页高速缓存，它是一种对完整的数据页进行操作的磁盘高速缓存，即把磁盘的数据块缓存在页高速缓存中。而address_space对页高速缓存进行管理。

2页高速缓存介绍

linux中几乎所有文件的读和写操作都依赖于页高速缓存。只有在O_DIRECT标志置为才会出现意外：此时，I/O数据的传送绕过了页高速缓存而使用了进程用户态地址空间的缓冲区；另外，少量的数据库软件为了采用自己的磁盘高速缓存算法而使用了O_DIRECT标志。

why设计页高速缓存？

答：1.快速定位所有者相关数据页的位置（基树）。2.区分不同所有者页的不同读写操作，如普通文件、块设备文件、交换区文件读一个数据页必须使用不同的方式实现，故内核根据页的不同所有者进行不同的操作。

3address_space对象

每一个所有者(可以理解为一个具体的文件，一个inode指向的文件)对应着一个address_space对象，页高速缓存的多个页可能属于一个所有者，从而可以链接到一个address_space对象。那么一个页（page）怎么和一个address_space产生关联的呢？

page中有两个字段：mapping和index。其中mapping指向该页所有者的address_mapping(内存inode结构有一个i_mapping指向对应address_space对象),index字段表示所有者地址空间中以页大小为单位的偏移量。用这两个字段就能在页高速缓存中查找也。（这里注意一点，一个页中所包含的磁盘块在物理上不一定是相邻的）

address_space中有一个host字段，该字段指向其所属的inode，也就是address_space中的host字段 与 对应inode中的 i_data字段形成互相指向的关系。若为普通文件，那么inode结点和address_space结构的相应指针的指向关系如下图：

4基树

linux支持TB级的文件，ext4甚至支持到了PB级文件，访问大文件时，高速缓存中存在着有关该文件太多的页，故设计了基树这个结构来加快查找。一个address_space对象对应一个基树。

address_space中有一个字段（page_tree）指向是基树的根（radix_tree_node）。基树根中的rnode指向基树的最高层节点（radix_tree_node）,基树节点都是radix_tree_node结构，节点中存放的都是指针，叶子节点的指针指向页描述符，上层节点指向存放其他节点的指针。一般一个radix_tree_node最多可以有64个指针，字段count表示该radix_tree_node已用节点数。

怎么快速找到所需页在基树中的位置呢？

回顾本科所学知识：分页系统如何利用页表实现线性地址到物理地址的转换？线性地址的最高20位分为两个10为的字段：第一个字段是页目录的偏移，第二个字段是页目录所指向也表的偏移。

在基树中，类比此方法。若基树深度为1，则只能表示从0至63的索引，则页索引（上文提高的index字段）的低6位进行解析，从而对应成radix_tree_node结构中的slot下标，找到对应的页；若基树深度为2，则页索引的低12位分成0~5,6~11两个字段进行解析。分别找到第一层slot字段和第二层slot字段的值。