Linux 深刻理解inode/block/superblock

  

基础命令学习目录首页

 

原文连接：https://blog.csdn.net/Ohmyberry/article/details/80427492

档案系统特性

传统的磁盘与档案系统之应用中，一个分割槽就是只可以被格式化成为一个档案系统，因此咱们能够说一个filesystem就是一个partition。可是因为新技术的利用，例如咱们常听到的LVM与软体磁盘阵列(software raid)，这些技术能够将一个分割槽格式化为多个档案系统(例如LVM)，也可以将多个分割槽合成一个档案系统(LVM, RAID)！因此说，目前咱们在格式化时已经再也不说成针对partition来格式化了，一般咱们能够称呼一个可被挂载的资料为一个档案系统而不是一个分割槽喔！

那么档案系统是如何运做的呢？这与做业系统的档案资料有关。较新的做业系统的档案资料除了档案实际内容外，一般含有很是多的属性，例如Linux做业系统的档案权限(rwx)与档案属性(拥有者、群组、时间参数等)。 档案系统一般会将这两部份的资料分别存放在不一样的区块，权限与属性放置到inode中，至于实际资料则放置到data block区块中。另外，还有一个超级区块(superblock)会记录整个档案系统的总体信息，包括inode与block的总量、使用量、剩余量等。

每一个inode 与block 都有编号，至于这三个资料的意义能够简略说明以下：

• superblock：记录此filesystem 的总体信息，包括inode/block的总量、使用量、剩余量， 以及档案系统的格式与相关信息等；
• inode：记录档案的属性，一个档案占用一个inode，同时记录此档案的资料所在的block 号码；
• block：实际记录档案的内容，若档案太大时，会占用多个block 。

因为每一个inode 与block 都有编号，而每一个档案都会占用一个inode ，inode 内则有档案资料放置的block 号码。所以，咱们能够知道的是，若是可以找到档案的inode 的话，那么天然就会知道这个档案所放置资料的block 号码， 固然也就可以读出该档案的实际资料了。这是个比较有效率的做法，由于如此一来咱们的磁盘就可以在短期内读取出所有的资料， 读写的效能比较好啰。

咱们将inode 与block 区块用图解来讲明一下，以下图所示，档案系统先格式化出inode 与block 的区块，假设某一个档案的属性与权限资料是放置到inode 4 号(下图较小方格内)，而这个inode 记录了档案资料的实际放置点为2, 7, 13, 15 这四个block 号码，此时咱们的做业系统就可以据此来排列磁盘的读取顺序，能够一口气将四个block 内容读出来！那么资料的读取就如同下图中的箭头所指定的模样了。

这种资料存取的方法咱们称为索引式档案系统(indexed allocation)。那有没有其余的惯用档案系统能够比较一下啊？有的，那就是咱们惯用的U盘(快闪记忆体)，U盘使用的档案系统通常为FAT格式。FAT这种格式的档案系统并无inode存在，因此FAT没有办法将这个档案的全部block在一开始就读取出来。每一个block号码都记录在前一个block当中，他的读取方式有点像底下这样：

上图中咱们假设档案的资料依序写入1->7->4->15号这四个block 号码中， 但这个档案系统没有办法一口气就知道四个block 的号码，他得要一个一个的将block 读出后，才会知道下一个block 在何处。若是同一个档案资料写入的block 分散的太过厉害时，则咱们的磁盘读取头将没法在磁盘转一圈就读到全部的资料， 所以磁盘就会多转好几圈才能完整的读取到这个档案的内容！

经常会听到所谓的『碎片整理』吧？ 须要碎片整理的缘由就是档案写入的block太过于离散了，此时档案读取的效能将会变的不好所致。 这个时候能够透过碎片整理将同一个档案所属的blocks汇整在一块儿，这样资料的读取会比较容易啊！ 想固然尔，FAT的档案系统须要三不五时的碎片整理一下，那么Ext2是否须要磁盘重整呢？

因为Ext2 是索引式档案系统，基本上不太须要经常进行碎片整理的。可是若是档案系统使用过久， 经常删除/编辑/新增档案时，那么仍是可能会形成档案资料太过于离散的问题，此时或许会须要进行重整一下的。

Linux 的EXT2 档案系统(inode)

inode的内容在记录档案的权限与相关属性，至于block区块则是在记录档案的实际内容。并且档案系统一开始就将inode与block规划好了，除非从新格式化(或者利用resize2fs等指令变动档案系统大小)，不然inode与block固定后就再也不变更。可是若是仔细考虑一下，若是个人档案系统高达数百GB时，那么将全部的inode与block统统放置在一块儿将是很不智的决定，由于inode与block的数量太庞大，不容易管理。

为此，所以Ext2 档案系统在格式化的时候基本上是区分为多个区块群组(block group) 的，每一个区块群组都有独立的 inode/block/superblock 系统。感受上就好像咱们在当兵时，一个营里面有分红数个连，每一个连有本身的联络系统， 但最终都向营部回报连上最正确的信息通常！这样分红一群群的比较好管理啦！整个来讲，Ext2 格式化后有点像底下这样：

在总体的规划当中，档案系统最前面有一个开机磁区(boot sector)，这个开机磁区能够安装开机管理程式，这是个很是重要的设计，由于如此一来咱们就可以将不一样的开机管理程式安装到个别的档案系统最前端，而不用覆盖整颗磁盘惟一的MBR，这样也才可以制做出多重开机的环境啊！至于每个区块群组(block group)的六个主要内容说明如后：

data block (资料区块)

data block是用来放置档案内容资料地方，在Ext2档案系统中所支持的block大小有1K, 2K及4K三种而已。在格式化时block的大小就固定了，且每一个block都有编号，以方便inode的记录啦。不过要注意的是，因为block大小的差别，会致使该档案系统可以支持的最大磁盘容量与最大单一档案容量并不相同。由于block大小而产生的Ext2档案系统限制以下：

Block 大小	1KB	2KB	4KB
最大单一档案限制	16GB	256GB	2TB
最大档案系统总容量	2TB	8TB	16TB

除此以外Ext2 档案系统的block 还有什么限制呢？有的！基本限制以下：

• 原则上，block 的大小与数量在格式化完就不可以再改变了(除非从新格式化)；
• 每一个block 内最多只可以放置一个档案的资料；
• 承上，若是档案大于block 的大小，则一个档案会占用多个block 数量；
• 承上，若档案小于block ，则该block 的剩余容量就不可以再被使用了(磁盘空间会浪费)。

inode table (inode 表格)

基本上，inode记录的档案资料至少有底下这些：

• 该档案的存取模式(read/write/excute)；
• 该档案的拥有者与群组(owner/group)；
• 该档案的容量；
• 该档案创建或状态改变的时间(ctime)；
• 最近一次的读取时间(atime)；
• 最近修改的时间(mtime)；
• 定义档案特性的旗标(flag)，如SetUID…；
• 该档案真正内容的指向(pointer)；

inode 的数量与大小也是在格式化时就已经固定了，除此以外inode 还有些什么特点呢？

• 每一个inode 大小均固定为128 bytes (新的ext4 与xfs 可设定到256 bytes)；
• 每一个档案都仅会占用一个inode 而已；
• 承上，所以档案系统可以创建的档案数量与inode 的数量有关；
• 系统读取档案时须要先找到inode，并分析inode 所记录的权限与使用者是否符合，若符合才可以开始实际读取 block 的内容。

咱们粗略来分析一下EXT2 的inode / block 与档案大小的关系好了。inode 要记录的资料很是多，但恰恰又只有128bytes 而已， 而inode 记录一个block 号码要花掉4byte ，假设我一个档案有400MB 且每一个block 为4K 时， 那么至少也要十万笔block 号码的记录呢！inode 哪有这么多可记录的信息？为此咱们的系统很聪明的将inode 记录block 号码的区域定义为12个直接，一个间接, 一个双间接与一个三间接记录区。这是啥？咱们将inode 的结构画一下好了。

这样子inode 可以指定多少个block 呢？咱们以较小的1K block 来讲明好了，能够指定的状况以下：

• 12个直接指向： 12*1K=12K
  因为是直接指向，因此总共可记录12笔记录，所以总额大小为如上所示；
• 间接： 256*1K=256K
  每笔block号码的记录会花去4bytes，所以1K的大小可以记录256笔记录，所以一个间接能够记录的档案大小如上；
• 双间接： 256*256*1K=256 2 K
  第一层block会指定256个第二层，每一个第二层能够指定256个号码，所以总额大小如上；
• 三间接： 256*256*256*1K=256 3 K
  第一层block会指定256个第二层，每一个第二层能够指定256个第三层，每一个第三层能够指定256个号码，所以总额大小如上；
• 总额：将直接、间接、双间接、三间接加总，获得12 + 256 + 256*256 + 256*256*256 (K) = 16GB

Superblock (超级区块)

记录的信息主要有：

• block 与inode 的总量；
• 未使用与已使用的inode / block 数量；
• block 与inode 的大小(block 为1, 2, 4K，inode 为128bytes 或256bytes)；
• filesystem 的挂载时间、最近一次写入资料的时间、最近一次检验磁盘(fsck) 的时间等档案系统的相关信息；
• 一个valid bit 数值，若此档案系统已被挂载，则valid bit 为0 ，若未被挂载，则valid bit 为1 。

通常来讲， superblock的大小为1024bytes。相关的superblock讯息咱们等一下会以dumpe2fs指令来呼叫出来观察喔！

此外，每一个block group 均可能含有superblock 喔！可是咱们也说一个档案系统应该仅有一个superblock 而已，那是怎么回事啊？事实上除了第一个block group 内会含有superblock 以外，后续的block group 不必定含有superblock ， 而若含有superblock 则该superblock 主要是作为第一个block group 内superblock 的备份咯，这样能够进行superblock的救援呢！

Filesystem Description (档案系统描述说明)

这个区段能够描述每一个block group的开始与结束的block号码，以及说明每一个区段(superblock, bitmap, inodemap, data block)分别介于哪个block号码之间。这部份也可以用dumpe2fs来观察的。

block bitmap (区块对照表)

若是你想要新增档案时总会用到block 吧！那你要使用哪一个block 来记录呢？固然是选择『空的block 』来记录新档案的资料啰。那你怎么知道哪一个block 是空的？这就得要透过block bitmap 的辅助了。从block bitmap 当中能够知道哪些block 是空的，所以咱们的系统就可以很快速的找到可以使用的空间来处置档案啰。

一样的，若是你删除某些档案时，那么那些档案本来占用的block 号码就得要释放出来， 此时在block bitmap 当中相对应到该block 号码的标志就得要修改为为『未使用中』啰！这就是bitmap 的功能。

inode bitmap (inode 对照表)

这个其实与block bitmap 是相似的功能，只是block bitmap 记录的是使用与未使用的block 号码， 至于inode bitmap 则是记录使用与未使用的inode 号码啰！

dumpe2fs： 查询Ext 家族superblock 信息的指令

[root@study ~]# dumpe2fs [-bh]装置档名 选项与参数： -b ：列出保留为坏轨的部分(通常用不到吧！？) -h ：仅列出superblock 的资料，不会列出其余的区段内容！ 范例：鸟哥的一块1GB ext4档案系统内容 [root@study ~]# blkid <==这个指令能够叫出目前系统有被格式化的装置 /dev/vda1: LABEL="myboot" UUID="ce4dbf1b-2b3d-4973-8234-73768e8fd659" TYPE="xfs" /dev/vda2: LABEL="myroot" UUID="21ad8b9a-aaad-443c-b732-4e2522e95e23" TYPE="xfs" /dev/vda3: UUID="12y99K-bv2A-y7RY-jhEW-rIWf-PcH5-SaiApN" TYPE="LVM2_member" /dev/vda5: UUID="e20d65d9-20d4-472f-9f91-cdcfb30219d6" TYPE="ext4" <==看到ext4了！ [root@study ~]# dumpe2fs /dev/vda5 dumpe2fs 1.42.9 (28-Dec-2013) Filesystem volume name: <none> #档案系统的名称(不必定会有) Last mounted on: <not available> #上一次挂载的目录位置 Filesystem UUID: e20d65d9-20d4-472f-9f91-cdcfb30219d6 Filesystem magic number: 0xEF53 #上方的UUID为Linux对装置的定义码 Filesystem revision #: 1 (dynamic) #下方的features为档案系统的特征资料 Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl #预设在挂载时会主动加上的挂载参数 Filesystem state: clean #这块档案系统的状态为什么，clean是没问题 Errors behavior: Continue Filesystem OS type: Linux Inode count: 65536 # inode的总数 Block count: 262144 # block的总数 Reserved block count: 13107 #保留的block总数 Free blocks: 249189 #还有多少的block可用数量 Free inodes: 65525 #还有多少的inode可用数量 First block: 0 Block size: 4096 #单个block的容量大小 Fragment size: 4096 Group descriptor size: 64 ....(中间省略).... Inode size: 256 # inode的容量大小！已是256了喔！ ....(中间省略).... Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 3c2568b4-1a7e-44cf-95a2-c8867fb19fbc Journal backup: inode blocks Journal features: (none) Journal size: 32M # Journal日志式资料的可供纪录总容量 Journal length: 8192 Journal sequence: 0x00000001 Journal start: 0 Group 0: (Blocks 0-32767) #第一块block group位置 Checksum 0x13be, unused inodes 8181 Primary superblock at 0, Group descriptors at 1-1 #主要superblock的所在喔！ Reserved GDT blocks at 2-128 Block bitmap at 129 (+129), Inode bitmap at 145 (+145) Inode table at 161-672 (+161) # inode table的所在喔！ 28521 free blocks, 8181 free inodes, 2 directories, 8181 unused inodes Free blocks: 142-144, 153-160, 4258-32767 #底下两行说明剩余的容量有多少 Free inodes: 12-8192 Group 1: (Blocks 32768-65535) [INODE_UNINIT] #后续为更多其余的block group喔！ ....(底下省略).... #因为资料量很是的庞大，所以鸟哥将一些信息省略输出了！上表与你的萤幕会有点差别。 # 前半部在秀出supberblock 的内容，包括标头名称(Label)以及inode/block的相关信息 # 后面则是每一个block group 的个别信息了！您能够看到各区段资料所在的号码！ # 也就是说，基本上全部的资料仍是与block 的号码有关就是了！很重要！

 

至于block group 的内容咱们单纯看Group0 信息好了。从上表中咱们能够发现：

• Group0 所占用的block 号码由0 到32767 号，superblock 则在第0 号的block 区块内！
• 档案系统描述说明在第1 号block 中；
• block bitmap 与inode bitmap 则在129 及145 的block 号码上。
• 至于inode table 分布于161-672 的block 号码中！
• 因为(1)一个inode 占用256 bytes ，(2)总共有672 - 161 + 1(161自己) = 512 个block 花在inode table 上， (3)每一个block 的大小为4096 bytes(4K)。由这些数据能够算出inode 的数量共有512 * 4096 / 256 = 8192 个inode 啦！
• 这个Group0 目前可用的block 有28521 个，可用的inode 有8181 个；
• 剩余的inode 号码为12 号到8192 号。

与目录树的关系

由前一小节的介绍咱们知道在Linux系统下，每一个档案(无论是通常档案仍是目录档案)都会占用一个inode ，且可依据档案内容的大小来分配多个block给该档案使用。那么目录与档案在档案系统当中是如何记录资料的呢？基本上能够这样说：

目录

当咱们在Linux下的档案系统创建一个目录时，档案系统会分配一个inode与至少一块block给该目录。其中，inode记录该目录的相关权限与属性，并可记录分配到的那块block号码；而block则是记录在这个目录下的档名与该档名占用的inode号码资料。

若是想要实际观察root 家目录内的档案所占用的inode 号码时，可使用ls -i 这个选项来处理：

[root@study ~]# ls -li total 8 53735697 -rw-------. 1 root root 1816 May 4 17:57 anaconda-ks.cfg 53745858 -rw-r--r--. 1 root root 1864 May 4 18:01 initial-setup-ks .cfg

 

而由这个目录的block 结果咱们如今就可以知道， 当你使用『 ll / 』时，出现的目录几乎都是1024 的倍数，为何呢？由于每一个block 的数量都是1K, 2K, 4K 嘛！

[root@study ~]# ll -d / /boot /usr/sbin /proc /sys 
dr-xr-xr-x. 17 root root 4096 May 4 17:56 / <== 1个4K block dr-xr- xr-x. 4 root root 4096 May 4 17:59 /boot <== 1个4K block dr-xr-xr-x. 155 root root 0 Jun 15 15:43 /proc <==这两个为记忆体内资料，不占磁盘容量 dr-xr-xr-x. 13 root root 0 Jun 15 23:43 /sys dr-xr-xr-x. 2 root root 16384 May 4 17:55 /usr/sbin <== 4个4K block

档案：

当咱们在Linux 下的ext2 创建一个通常档案时， ext2 会分配一个inode 与相对于该档案大小的block 数量给该档案。例如：假设个人一个block 为4 Kbytes ，而我要创建一个100 KBytes 的档案，那么linux 将分配一个inode 与25 个block 来储存该档案！但同时请注意，因为inode 仅有12 个直接指向，所以还要多一个block 来做为区块号码的记录喔！

目录树读取：

咱们提到『新增/删除/改名档名与目录的w权限有关』！那是由于档名是记录在目录的block当中，所以当咱们要读取某个档案时，就务必会通过目录的inode与block ，而后才可以找到那个待读取档案的inode号码，最终才会读到正确的档案的block内的资料。

因为目录树是由根目录开始读起，所以系统透过挂载的信息能够找到挂载点的inode 号码，此时就可以获得根目录的inode 内容，并依据该inode 读取根目录的block 内的档名资料，再一层一层的往下读到正确的档名。举例来讲，若是我想要读取/etc/passwd 这个档案时，系统是如何读取的呢？

[root@study ~]# ll -di / /etc /etc/passwd 128 dr-xr-x r-x . 17 root root 4096 May 4 17:56 / 33595521 drwxr-x r-x . 131 root root 8192 Jun 17 00:20 /etc 36628004 -rw-r-- r-- . 1 root root 2092 Jun 17 00:20 /etc/passw

 

该档案的读取流程为(假设读取者身份为dmtsai 这个通常身份使用者)：

1. /的inode：
   透过挂载点的信息找到inode号码为128的根目录inode，且inode的权限属性容许咱们能够读取该block的内容(有r与x) ；
2. /的block：
   通过上个步骤取得block的号码，并找到该内容有etc/目录的inode号码(33595521)；
3. etc/的inode：
   读取33595521号inode得知dmtsai具备r与x的权限，所以能够读取etc/的block内容；
4. etc/的block：
   通过上个步骤取得block号码，并找到该内容有passwd档案的inode号码(36628004)；
5. passwd的inode：
   读取36628004号inode得知dmtsai具备r的权限，所以能够读取passwd的block内容；
6. passwd的block： 最后将该block内容的资料读出来。