原文：https://wizardforcel.gitbooks.io/vbird-linux-basic-4e/content/59.html
Linux 最传统的磁盘文件系统 （filesystem） 使用的是 EXT2 这个啦！所以要了解 Linux 的文件系统就得要由认识 EXT2 开始！ 而文件系统是创建在磁盘上面的，因此我们得了解磁盘的物理组成才行。磁盘物理组成的部分我们在第零章谈过了，至于磁盘分区则在第二章谈过了，所以下面只会很快的复习这两部份。 重点在于 inode, block 还有 superblock 等文件系统的基本部分喔！
由于各项磁盘的物理组成我们在第零章里面就介绍过， 同时第二章也谈过分区的概念了，所以这个小节我们就拿之前的重点出来介绍就好了！ 详细的信息请您回去那两章自行复习喔！^_^。好了，首先说明一下磁盘的物理组成，整颗磁盘的组成主要有：
圆形的盘片（主要记录数据的部分）；机械手臂，与在机械手臂上的磁头（可读写盘片上的数据）；主轴马达，可以转动盘片，让机械手臂的磁头在盘片上读写数据。从上面我们知道数据储存与读取的重点在于盘片，而盘片上的物理组成则为（假设此磁盘为单碟片， 盘片图示请参考第二章图2.2.1的示意）：
扇区（Sector）为最小的物理储存单位，且依据磁盘设计的不同，目前主要有 512Bytes 与 4K 两种格式；将扇区组成一个圆，那就是柱面（Cylinder）；早期的分区主要以柱面为最小分区单位，现在的分区通常使用扇区为最小分区单位（每个扇区都有其号码喔，就好像座位一样）；磁盘分区表主要有两种格式，一种是限制较多的 MBR 分区表，一种是较新且限制较少的 GPT 分区表。MBR 分区表中，第一个扇区最重要，里面有：（1）主要开机区（Master boot record, MBR）及分区表（partition table）， 其中 MBR 占有 446 Bytes，而 partition table 则占有 64 Bytes。GPT 分区表除了分区数量扩充较多之外，支持的磁盘容量也可以超过 2TB。至于磁盘的文件名部份，基本上，所有实体磁盘的文件名都已经被仿真成 /dev/sd[a-p] 的格式，第一颗磁盘文件名为 /dev/sda。 而分区的文件名若以第一颗磁盘为例，则为 /dev/sda[1-128] 。除了实体磁盘之外，虚拟机的磁盘通常为 /dev/vd[a-p] 的格式。 若有使用到软件磁盘阵列的话，那还有 /dev/md[0-128] 的磁盘文件名。使用的是 LVM 时，文件名则为 /dev/VGNAME/LVNAME 等格式。 关于软件磁盘阵列与 LVM 我们会在后面继续介绍，这里主要介绍的以实体磁盘及虚拟磁盘为主喔！
/dev/sd[a-p][1-128]：为实体磁盘的磁盘文件名；/dev/vd[a-d][1-128]：为虚拟磁盘的磁盘文件名复习完物理组成后，来复习一下磁盘分区吧！如前所述，以前磁盘分区最小单位经常是柱面，但 CentOS 7 的分区软件， 已经将最小单位改成扇区了，所以容量大小的分区可以切的更细～此外，由于新的大容量磁盘大多得要使用 GPT 分区表才能够使用全部的容量， 因此过去那个 MBR 的传统磁盘分区表限制就不会存在了。不过，由于还是有小磁盘啊！因此， 你在处理分区的时候，还是得要先查询一下，你的分区是 MBR 的分区？还是 GPT 的分区？在第三章的 CentOS 7 安装中， 鸟哥建议过强制使用 GPT 分区喔！所以本章后续的动作，大多还是以 GPT 为主来介绍喔！旧的 MBR 相关限制回去看看第二章吧！
我们都知道磁盘分区完毕后还需要进行格式化（format），之后操作系统才能够使用这个文件系统。 为什么需要进行“格式化”呢？这是因为每种操作系统所设置的文件属性/权限并不相同， 为了存放这些文件所需的数据，因此就需要将分区进行格式化，以成为操作系统能够利用的“文件系统格式（filesystem）”。
由此我们也能够知道，每种操作系统能够使用的文件系统并不相同。 举例来说，windows 98 以前的微软操作系统主要利用的文件系统是 FAT （或 FAT16），windows 2000 以后的版本有所谓的 NTFS 文件系统，至于 Linux 的正统文件系统则为 Ext2 （Linux second extended file system, ext2fs）这一个。此外，在默认的情况下，windows 操作系统是不会认识 Linux 的 Ext2 的。
传统的磁盘与文件系统之应用中，一个分区就是只能够被格式化成为一个文件系统，所以我们可以说一个 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 内容读出来！ 那么数据的读取就如同下图中的箭头所指定的模样了。
图7.1.1、inode/block 数据存取示意图
这种数据存取的方法我们称为索引式文件系统（indexed allocation）。那有没有其他的惯用文件系统可以比较一下啊？ 有的，那就是我们惯用的U盘（闪存），U盘使用的文件系统一般为 FAT 格式。FAT 这种格式的文件系统并没有 inode 存在，所以 FAT 没有办法将这个文件的所有 block 在一开始就读取出来。每个 block 号码都记录在前一个 block 当中， 他的读取方式有点像下面这样：
图7.1.2、FAT文件系统数据存取示意图
上图中我们假设文件的数据依序写入1->7->4->15号这四个 block 号码中， 但这个文件系统没有办法一口气就知道四个 block 的号码，他得要一个一个的将 block 读出后，才会知道下一个 block 在何处。 如果同一个文件数据写入的 block 分散的太过厉害时，则我们的磁头将无法在磁盘转一圈就读到所有的数据， 因此磁盘就会多转好几圈才能完整的读取到这个文件的内容！
常常会听到所谓的“磁盘重组”吧？ 需要磁盘重组的原因就是文件写入的 block 太过于离散了，此时文件读取的性能将会变的很差所致。 这个时候可以通过磁盘重组将同一个文件所属的 blocks 汇整在一起，这样数据的读取会比较容易啊！ 想当然尔，FAT 的文件系统需要三不五时的磁盘重组一下，那么 Ext2 是否需要磁盘重整呢？
由于 Ext2 是索引式文件系统，基本上不太需要常常进行磁盘重组的。但是如果文件系统使用太久， 常常删除/编辑/新增文件时，那么还是可能会造成文件数据太过于离散的问题，此时或许会需要进行重整一下的。 不过，老实说，鸟哥倒是没有在 Linux 操作系统上面进行过 Ext2/Ext3 文件系统的磁盘重组说！似乎不太需要啦！^_^
在第五章当中我们介绍过 Linux 的文件除了原有的数据内容外，还含有非常多的权限与属性，这些权限与属性是为了保护每个使用者所拥有数据的隐密性。 而前一小节我们知道 filesystem 里面可能含有的 inode/block/superblock 等。为什么要谈这个呢？因为标准的 Linux 文件系统 Ext2 就是使用这种 inode 为基础的文件系统啦！
而如同前一小节所说的，inode 的内容在记录文件的权限与相关属性，至于 block 区块则是在记录文件的实际内容。 而且文件系统一开始就将 inode 与 block 规划好了，除非重新格式化（或者利用 resize2fs 等指令变更文件系统大小），否则 inode 与 block 固定后就不再变动。但是如果仔细考虑一下，如果我的文件系统高达数百GB时， 那么将所有的 inode 与 block 通通放置在一起将是很不智的决定，因为 inode 与 block 的数量太庞大，不容易管理。
为此之故，因此 Ext2 文件系统在格式化的时候基本上是区分为多个区块群组 （block group） 的，每个区块群组都有独立的 inode/block/superblock 系统。感觉上就好像我们在当兵时，一个营里面有分成数个连，每个连有自己的联络系统， 但最终都向营部回报连上最正确的信息一般！这样分成一群群的比较好管理啦！整个来说，Ext2 格式化后有点像下面这样：
图7.1.3、ext2文件系统示意图 [1]
在整体的规划当中，文件系统最前面有一个开机扇区（boot sector），这个开机扇区可以安装开机管理程序， 这是个非常重要的设计，因为如此一来我们就能够将不同的开机管理程序安装到个别的文件系统最前端，而不用覆盖整颗磁盘唯一的 MBR， 这样也才能够制作出多重开机的环境啊！至于每一个区块群组（block group）的六个主要内容说明如后：
data block （数据区块）data block 是用来放置文件内容数据地方，在 Ext2 文件系统中所支持的 block 大小有 1K, 2K 及 4K 三种而已。在格式化时 block 的大小就固定了，且每个 block 都有编号，以方便 inode 的记录啦。 不过要注意的是，由于 block 大小的差异，会导致该文件系统能够支持的最大磁盘容量与最大单一文件大小并不相同。 因为 block 大小而产生的 Ext2 文件系统限制如下：[2]
Block 大小1KB2KB4KB最大单一文件限制16GB256GB2TB最大文件系统总容量2TB8TB16TB你需要注意的是，虽然 Ext2 已经能够支持大于 2GB 以上的单一文件大小，不过某些应用程序依然使用旧的限制， 也就是说，某些程序只能够捉到小于 2GB 以下的文件而已，这就跟文件系统无关了！ 举例来说，鸟哥在环工方面的应用中有一套秀图软件称为PAVE[3]， 这套软件就无法捉到鸟哥在数值模式仿真后产生的大于 2GB 以上的文件！所以后来只能找更新的软件来取代它了！
除此之外 Ext2 文件系统的 block 还有什么限制呢？有的！基本限制如下：
原则上，block 的大小与数量在格式化完就不能够再改变了（除非重新格式化）；每个 block 内最多只能够放置一个文件的数据；承上，如果文件大于 block 的大小，则一个文件会占用多个 block 数量；承上，若文件小于 block ，则该 block 的剩余容量就不能够再被使用了（磁盘空间会浪费）。如上第四点所说，由于每个 block 仅能容纳一个文件的数据而已，因此如果你的文件都非常小，但是你的 block 在格式化时却选用最大的 4K 时，可能会产生一些容量的浪费喔！我们以下面的一个简单例题来算一下空间的浪费吧！
例题：假设你的Ext2文件系统使用 4K block ，而该文件系统中有 10000 个小文件，每个文件大小均为 50Bytes， 请问此时你的磁盘浪费多少容量？答：由于 Ext2 文件系统中一个 block 仅能容纳一个文件，因此每个 block 会浪费“ 4096 - 50 = 4046 （Byte）”， 系统中总共有一万个小文件，所有文件大小为：50 （Bytes） x 10000 = 488.3KBytes，但此时浪费的容量为：“ 4046 （Bytes） x 10000 = 38.6MBytes ”。想一想，不到 1MB 的总文件大小却浪费将近 40MB 的容量，且文件越多将造成越多的磁盘容量浪费。
什么情况会产生上述的状况呢？例如 BBS 网站的数据啦！如果 BBS 上面的数据使用的是纯文本来记载每篇留言， 而留言内容如果都写上“如题”时，想一想，是否就会产生很多小文件了呢？
好，既然大的 block 可能会产生较严重的磁盘容量浪费，那么我们是否就将 block 大小订为 1K 即可？ 这也不妥，因为如果 block 较小的话，那么大型文件将会占用数量更多的 block ，而 inode 也要记录更多的 block 号码，此时将可能导致文件系统不良的读写性能。
所以我们可以说，在您进行文件系统的格式化之前，请先想好该文件系统预计使用的情况。 以鸟哥来说，我的数值模式仿真平台随便一个文件都好几百 MB，那么 block 容量当然选择较大的！至少文件系统就不必记录太多的 block 号码，读写起来也比较方便啊！
Tips 事实上，现在的磁盘容量都太大了！所以，大概大家都只会选择 4K 的 block 大小吧！呵呵！
inode table （inode 表格）再来讨论一下 inode 这个玩意儿吧！如前所述 inode 的内容在记录文件的属性以及该文件实际数据是放置在哪几号 block 内！ 基本上，inode 记录的文件数据至少有下面这些：[4]
该文件的存取模式（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 的结构画一下好了。
图7.1.4、inode 结构示意图
上图最左边为 inode 本身 （128 Bytes），里面有 12 个直接指向 block 号码的对照，这 12 笔记录就能够直接取得 block 号码啦！ 至于所谓的间接就是再拿一个 block 来当作记录 block 号码的记录区，如果文件太大时， 就会使用间接的 block 来记录号码。如上图 7.1.4 当中间接只是拿一个 block 来记录额外的号码而已。 同理，如果文件持续长大，那么就会利用所谓的双间接，第一个 block 仅再指出下一个记录号码的 block 在哪里， 实际记录的在第二个 block 当中。依此类推，三间接就是利用第三层 block 来记录号码啦！
这样子 inode 能够指定多少个 block 呢？我们以较小的 1K block 来说明好了，可以指定的情况如下：
12 个直接指向： 12*1K=12K 由于是直接指向，所以总共可记录 12 笔记录，因此总额大小为如上所示；
间接： 256*1K=256K 每笔 block 号码的记录会花去 4Bytes，因此 1K 的大小能够记录 256 笔记录，因此一个间接可以记录的文件大小如上；
双间接： 2562561K=2562K 第一层 block 会指定 256 个第二层，每个第二层可以指定 256 个号码，因此总额大小如上；
三间接： 256256256*1K=2563K 第一层 block 会指定 256 个第二层，每个第二层可以指定 256 个第三层，每个第三层可以指定 256 个号码，因此总额大小如上；
总额：将直接、间接、双间接、三间接加总，得到 12 + 256 + 256256 + 256256*256 （K） = 16GB
此时我们知道当文件系统将 block 格式化为 1K 大小时，能够容纳的最大文件为 16GB，比较一下文件系统限制表的结果可发现是一致的！但这个方法不能用在 2K 及 4K block 大小的计算中， 因为大于 2K 的 block 将会受到 Ext2 文件系统本身的限制，所以计算的结果会不太符合之故。
Tips 如果你的 Linux 依旧使用 Ext2/Ext3/Ext4 文件系统的话，例如鸟哥之前的 CentOS 6.x 系统，那么默认还是使用 Ext4 的文件系统喔！ Ext4 文件系统的 inode 容量已经可以扩大到 256Bytes 了，更大的 inode 容量，可以纪录更多的文件系统信息，包括新的 ACL 以及 SELinux 类型等， 当然，可以纪录的单一文件大小达 16TB 且单一文件系统总容量可达 1EB 哩！
Superblock （超级区块）Superblock 是记录整个 filesystem 相关信息的地方， 没有 Superblock ，就没有这个 filesystem 了。他记录的信息主要有：
block 与 inode 的总量；未使用与已使用的 inode / block 数量；block 与 inode 的大小 （block 为 1, 2, 4K，inode 为 128Bytes 或 256Bytes）；filesystem 的挂载时间、最近一次写入数据的时间、最近一次检验磁盘 （fsck） 的时间等文件系统的相关信息；一个 valid bit 数值，若此文件系统已被挂载，则 valid bit 为 0 ，若未被挂载，则 valid bit 为 1 。Superblock 是非常重要的，因为我们这个文件系统的基本信息都写在这里，因此，如果 superblock 死掉了， 你的文件系统可能就需要花费很多时间去挽救啦！一般来说， 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 信息的指令了解了文件系统的概念之后，再来当然是观察这个文件系统啰！刚刚谈到的各部分数据都与 block 号码有关！ 每个区段与 superblock 的信息都可以使用 dumpe2fs 这个指令来查询的！不过很可惜的是，我们的 CentOS 7 现在是以 xfs 为默认文件系统， 所以目前你的系统应该无法使用 dumpe2fs 去查询任何文件系统的。没关系，鸟哥先找自己的一部机器来跟大家介绍， 你可以在后续的格式化内容讲完之后，自己切出一个 ext4 的文件系统去查询看看即可。鸟哥这块文件系统是 1GB 的容量，使用默认方式来进行格式化的， 观察的内容如下：
[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 的号码有关就是了！很重要！如上所示，利用 dumpe2fs 可以查询到非常多的信息，不过依内容主要可以区分为上半部是 superblock 内容， 下半部则是每个 block group 的信息了。从上面的表格中我们可以观察到鸟哥这个 /dev/vda5 规划的 block 为 4K， 第一个 block 号码为 0 号，且 block group 内的所有信息都以 block 的号码来表示的。 然后在 superblock 中还有谈到目前这个文件系统的可用 block 与 inode 数量喔！
至于 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 号码数据。也就是说目录所占用的 block 内容在记录如下的信息：
图7.1.5、记载于目录所属的 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由于每个人所使用的计算机并不相同，系统安装时选择的项目与 partition 都不一样，因此你的环境不可能与我的 inode 号码一模一样！上表的左边所列出的 inode 仅是鸟哥的系统所显示的结果而已！而由这个目录的 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由于鸟哥的根目录使用的 block 大小为 4K ，因此每个目录几乎都是 4K 的倍数。 其中由于 /usr/sbin 的内容比较复杂因此占用了 4 个 block ！至于奇怪的 /proc 我们在第五章就讲过该目录不占磁盘容量， 所以当然耗用的 block 就是 0 啰！
Tips 由上面的结果我们知道目录并不只会占用一个 block 而已，也就是说： 在目录下面的文件数如果太多而导致一个 block 无法容纳的下所有的文件名与 inode 对照表时，Linux 会给予该目录多一个 block 来继续记录相关的数据；
文件：当我们在 Linux 下的 ext2 创建一个一般文件时， ext2 会分配一个 inode 与相对于该文件大小的 block 数量给该文件。例如：假设我的一个 block 为 4 KBytes ，而我要创建一个 100 KBytes 的文件，那么 linux 将分配一个 inode 与 25 个 block 来储存该文件！ 但同时请注意，由于 inode 仅有 12 个直接指向，因此还要多一个 block 来作为区块号码的记录喔！
目录树读取：好了，经过上面的说明你也应该要很清楚的知道 inode 本身并不记录文件名，文件名的记录是在目录的 block 当中。 因此在第五章文件与目录的权限说明中， 我们才会提到“新增/删除/更名文件名与目录的 w 权限有关”的特色！那么因为文件名是记录在目录的 block 当中， 因此当我们要读取某个文件时，就务必会经过目录的 inode 与 block ，然后才能够找到那个待读取文件的 inode 号码， 最终才会读到正确的文件的 block 内的数据。
由于目录树是由根目录开始读起，因此系统通过挂载的信息可以找到挂载点的 inode 号码，此时就能够得到根目录的 inode 内容，并依据该 inode 读取根目录的 block 内的文件名数据，再一层一层的往下读到正确的文件名。举例来说，如果我想要读取 /etc/passwd 这个文件时，系统是如何读取的呢？
[root@study ~]# ll -di / /etc /etc/passwd 128 dr-xr-xr-x. 17 root root 4096 May 4 17:56 / 33595521 drwxr-xr-x. 131 root root 8192 Jun 17 00:20 /etc 36628004 -rw-r--r--. 1 root root 2092 Jun 17 00:20 /etc/passwd在鸟哥的系统上面与 /etc/passwd 有关的目录与文件数据如上表所示，该文件的读取流程为（假设读取者身份为 dmtsai 这个一般身份使用者）：
/ 的 inode： 通过挂载点的信息找到 inode 号码为 128 的根目录 inode，且 inode 规范的权限让我们可以读取该 block 的内容（有 r 与 x） ；
/ 的 block： 经过上个步骤取得 block 的号码，并找到该内容有 etc/ 目录的 inode 号码 （33595521）；
etc/ 的 inode： 读取 33595521 号 inode 得知 dmtsai 具有 r 与 x 的权限，因此可以读取 etc/ 的 block 内容；
etc/ 的 block： 经过上个步骤取得 block 号码，并找到该内容有 passwd 文件的 inode 号码 （36628004）；
passwd 的 inode： 读取 36628004 号 inode 得知 dmtsai 具有 r 的权限，因此可以读取 passwd 的 block 内容；
passwd 的 block： 最后将该 block 内容的数据读出来。
filesystem 大小与磁盘读取性能：
另外，关于文件系统的使用效率上，当你的一个文件系统规划的很大时，例如 100GB 这么大时， 由于磁盘上面的数据总是来来去去的，所以，整个文件系统上面的文件通常无法连续写在一起（block 号码不会连续的意思）， 而是填入式的将数据填入没有被使用的 block 当中。如果文件写入的 block 真的分的很散， 此时就会有所谓的文件数据离散的问题发生了。
如前所述，虽然我们的 ext2 在 inode 处已经将该文件所记录的 block 号码都记上了， 所以数据可以一次性读取，但是如果文件真的太过离散，确实还是会发生读取效率低落的问题。 因为磁头还是得要在整个文件系统中来来去去的频繁读取！ 果真如此，那么可以将整个 filesystme 内的数据全部复制出来，将该 filesystem 重新格式化， 再将数据给他复制回去即可解决这个问题。
此外，如果 filesystem 真的太大了，那么当一个文件分别记录在这个文件系统的最前面与最后面的 block 号码中， 此时会造成磁盘的机械手臂移动幅度过大，也会造成数据读取性能的低落。而且磁头在搜寻整个 filesystem 时， 也会花费比较多的时间去搜寻！因此， partition 的规划并不是越大越好， 而是真的要针对您的主机用途来进行规划才行！^_^
上一小节谈到的仅是读取而已，那么如果是新建一个文件或目录时，我们的文件系统是如何处理的呢？ 这个时候就得要 block bitmap 及 inode bitmap 的帮忙了！假设我们想要新增一个文件，此时文件系统的行为是：
先确定使用者对于欲新增文件的目录是否具有 w 与 x 的权限，若有的话才能新增；根据 inode bitmap 找到没有使用的 inode 号码，并将新文件的权限/属性写入；根据 block bitmap 找到没有使用中的 block 号码，并将实际的数据写入 block 中，且更新 inode 的 block 指向数据；将刚刚写入的 inode 与 block 数据同步更新 inode bitmap 与 block bitmap，并更新 superblock 的内容。一般来说，我们将 inode table 与 data block 称为数据存放区域，至于其他例如 superblock、 block bitmap 与 inode bitmap 等区段就被称为 metadata （中介数据） 啰，因为 superblock, inode bitmap 及 block bitmap 的数据是经常变动的，每次新增、移除、编辑时都可能会影响到这三个部分的数据，因此才被称为中介数据的啦。
数据的不一致 （Inconsistent） 状态在一般正常的情况下，上述的新增动作当然可以顺利的完成。但是如果有个万一怎么办？ 例如你的文件在写入文件系统时，因为不知名原因导致系统中断（例如突然的停电啊、 系统核心发生错误啊～等等的怪事发生时），所以写入的数据仅有 inode table 及 data block 而已， 最后一个同步更新中介数据的步骤并没有做完，此时就会发生 metadata 的内容与实际数据存放区产生不一致 （Inconsistent） 的情况了。
既然有不一致当然就得要克服！在早期的 Ext2 文件系统中，如果发生这个问题， 那么系统在重新开机的时候，就会借由 Superblock 当中记录的 valid bit （是否有挂载） 与 filesystem state （clean 与否） 等状态来判断是否强制进行数据一致性的检查！若有需要检查时则以 e2fsck 这支程序来进行的。
不过，这样的检查真的是很费时～因为要针对 metadata 区域与实际数据存放区来进行比对， 呵呵～得要搜寻整个 filesystem 呢～如果你的文件系统有 100GB 以上，而且里面的文件数量又多时， 哇！系统真忙碌～而且在对 Internet 提供服务的服务器主机上面， 这样的检查真的会造成主机复原时间的拉长～真是麻烦～这也就造成后来所谓日志式文件系统的兴起了。
日志式文件系统 （Journaling filesystem）为了避免上述提到的文件系统不一致的情况发生，因此我们的前辈们想到一个方式， 如果在我们的 filesystem 当中规划出一个区块，该区块专门在记录写入或修订文件时的步骤， 那不就可以简化一致性检查的步骤了？也就是说：
预备：当系统要写入一个文件时，会先在日志记录区块中纪录某个文件准备要写入的信息；实际写入：开始写入文件的权限与数据；开始更新 metadata 的数据；结束：完成数据与 metadata 的更新后，在日志记录区块当中完成该文件的纪录。在这样的程序当中，万一数据的纪录过程当中发生了问题，那么我们的系统只要去检查日志记录区块， 就可以知道哪个文件发生了问题，针对该问题来做一致性的检查即可，而不必针对整块 filesystem 去检查， 这样就可以达到快速修复 filesystem 的能力了！这就是日志式文件最基础的功能啰～
那么我们的 ext2 可达到这样的功能吗？当然可以啊！ 就通过 ext3/ext4 即可！ ext3/ext4 是 ext2 的升级版本，并且可向下相容 ext2 版本呢！ 所以啰，目前我们才建议大家，可以直接使用 ext4 这个 filesystem 啊！ 如果你还记得 dumpe2fs 输出的讯息，可以发现 superblock 里面含有下面这样的信息：
Journal inode: 8 Journal backup: inode blocks Journal features: （none） Journal size: 32M Journal length: 8192 Journal sequence: 0x00000001看到了吧！通过 inode 8 号记录 journal 区块的 block 指向，而且具有 32MB 的容量在处理日志呢！ 这样对于所谓的日志式文件系统有没有比较有概念一点呢？^_^。
我们现在知道了目录树与文件系统的关系了，但是由第零章的内容我们也知道， 所有的数据都得要载入到内存后 CPU 才能够对该数据进行处理。想一想，如果你常常编辑一个好大的文件， 在编辑的过程中又频繁的要系统来写入到磁盘中，由于磁盘写入的速度要比内存慢很多， 因此你会常常耗在等待磁盘的写入/读取上。真没效率！
为了解决这个效率的问题，因此我们的 Linux 使用的方式是通过一个称为非同步处理 （asynchronously） 的方式。所谓的非同步处理是这样的：
当系统载入一个文件到内存后，如果该文件没有被更动过，则在内存区段的文件数据会被设置为干净（clean）的。 但如果内存中的文件数据被更改过了（例如你用 nano 去编辑过这个文件），此时该内存中的数据会被设置为脏的 （Dirty）。此时所有的动作都还在内存中执行，并没有写入到磁盘中！ 系统会不定时的将内存中设置为“Dirty”的数据写回磁盘，以保持磁盘与内存数据的一致性。 你也可以利用第四章谈到的 sync指令来手动强迫写入磁盘。
我们知道内存的速度要比磁盘快的多，因此如果能够将常用的文件放置到内存当中，这不就会增加系统性能吗？ 没错！是有这样的想法！因此我们 Linux 系统上面文件系统与内存有非常大的关系喔：
系统会将常用的文件数据放置到内存的缓冲区，以加速文件系统的读/写；承上，因此 Linux 的实体内存最后都会被用光！这是正常的情况！可加速系统性能；你可以手动使用 sync 来强迫内存中设置为 Dirty 的文件回写到磁盘中；若正常关机时，关机指令会主动调用 sync 来将内存的数据回写入磁盘内；但若不正常关机（如跳电、死机或其他不明原因），由于数据尚未回写到磁盘内， 因此重新开机后可能会花很多时间在进行磁盘检验，甚至可能导致文件系统的损毁（非磁盘损毁）。每个 filesystem 都有独立的 inode / block / superblock 等信息，这个文件系统要能够链接到目录树才能被我们使用。 将文件系统与目录树结合的动作我们称为“挂载”。 关于挂载的一些特性我们在第二章稍微提过， 重点是：挂载点一定是目录，该目录为进入该文件系统的入口。 因此并不是你有任何文件系统都能使用，必须要“挂载”到目录树的某个目录后，才能够使用该文件系统的。
举例来说，如果你是依据鸟哥的方法安装你的 CentOS 7.x 的话， 那么应该会有三个挂载点才是，分别是 /, /boot, /home 三个 （鸟哥的系统上对应的设备文件名为 LVM, LVM, /dev/vda2）。 那如果观察这三个目录的 inode 号码时，我们可以发现如下的情况：
[root@study ~]# ls -lid / /boot /home 128 dr-xr-xr-x. 17 root root 4096 May 4 17:56 / 128 dr-xr-xr-x. 4 root root 4096 May 4 17:59 /boot 128 drwxr-xr-x. 5 root root 41 Jun 17 00:20 /home看到了吧！由于 XFS filesystem 最顶层的目录之 inode 一般为 128 号，因此可以发现 /, /boot, /home 为三个不同的 filesystem 啰！ （因为每一行的文件属性并不相同，且三个目录的挂载点也均不相同之故。） 我们在第六章一开始的路径中曾经提到根目录下的 . 与 .. 是相同的东西， 因为权限是一模一样嘛！如果使用文件系统的观点来看，同一个 filesystem 的某个 inode 只会对应到一个文件内容而已（因为一个文件占用一个 inode 之故）， 因此我们可以通过判断 inode 号码来确认不同文件名是否为相同的文件喔！所以可以这样看：
[root@study ~]# ls -ild / /. /.. 128 dr-xr-xr-x. 17 root root 4096 May 4 17:56 / 128 dr-xr-xr-x. 17 root root 4096 May 4 17:56 /. 128 dr-xr-xr-x. 17 root root 4096 May 4 17:56 /..上面的信息中由于挂载点均为 / ，因此三个文件 （/, /., /..） 均在同一个 filesystem 内，而这三个文件的 inode 号码均为 128 号，因此这三个文件名都指向同一个 inode 号码，当然这三个文件的内容也就完全一模一样了！ 也就是说，根目录的上层 （/..） 就是他自己！这么说，看的懂了吗？ ^_^
虽然 Linux 的标准文件系统是 ext2 ，且还有增加了日志功能的 ext3/ext4 ，事实上，Linux 还有支持很多文件系统格式的， 尤其是最近这几年推出了好几种速度很快的日志式文件系统，包括 SGI 的 XFS 文件系统， 可以适用更小型文件的 Reiserfs 文件系统，以及 Windows 的 FAT 文件系统等等， 都能够被 Linux 所支持喔！常见的支持文件系统有：
传统文件系统：ext2 / minix / MS-DOS / FAT （用 vfat 模块） / iso9660 （光盘）等等；日志式文件系统： ext3 /ext4 / ReiserFS / Windows' NTFS / IBM's JFS / SGI's XFS / ZFS网络文件系统： NFS / SMBFS想要知道你的 Linux 支持的文件系统有哪些，可以察看下面这个目录：
[root@study ~]# ls -l /lib/modules/$（uname -r）/kernel/fs系统目前已载入到内存中支持的文件系统则有：
[root@study ~]# cat /proc/filesystems Linux VFS （Virtual Filesystem Switch）了解了我们使用的文件系统之后，再来则是要提到，那么 Linux 的核心又是如何管理这些认识的文件系统呢？ 其实，整个 Linux 的系统都是通过一个名为 Virtual Filesystem Switch 的核心功能去读取 filesystem 的。 也就是说，整个 Linux 认识的 filesystem 其实都是 VFS 在进行管理，我们使用者并不需要知道每个 partition 上头的 filesystem 是什么～ VFS 会主动的帮我们做好读取的动作呢～
假设你的 / 使用的是 /dev/hda1 ，用 ext3 ，而 /home 使用 /dev/hda2 ，用 reiserfs ， 那么你取用 /home/dmtsai/.bashrc 时，有特别指定要用的什么文件系统的模块来读取吗？ 应该是没有吧！这个就是 VFS 的功能啦！通过这个 VFS 的功能来管理所有的 filesystem， 省去我们需要自行设置读取文件系统的定义啊～方便很多！整个 VFS 可以约略用下图来说明：
图7.1.6、VFS 文件系统的示意图
老实说，文件系统真的不好懂！ 如果你想要对文件系统有更深入的了解，文末的相关链接[5]务必要参考参考才好喔！
CentOS 7 开始，默认的文件系统已经由原本的 EXT4 变成了 XFS 文件系统了！为啥 CentOS 要舍弃对 Linux 支持度最完整的 EXT 家族而改用 XFS 呢？ 这是有一些原因存在的。
EXT 家族当前较伤脑筋的地方：支持度最广，但格式化超慢！Ext 文件系统家族对于文件格式化的处理方面，采用的是预先规划出所有的 inode/block/meta data 等数据，未来系统可以直接取用， 不需要再进行动态配置的作法。这个作法在早期磁盘容量还不大的时候还算 OK 没啥问题，但时至今日，磁盘容量越来越大，连传统的 MBR 都已经被 GPT 所取代，连我们这些老人家以前听到的超大 TB 容量也已经不够看了！现在都已经说到 PB 或 EB 以上容量了呢！那你可以想像得到，当你的 TB 以上等级的传统 ext 家族文件系统在格式化的时候，光是系统要预先分配 inode 与 block 就消耗你好多好多的人类时间了...
Tips 之前格式化过一个 70 TB 以上的磁盘阵列成为 ext4 文件系统，按下格式化，去喝了咖啡、吃了便当才回来看做完了没有... 所以，后来立刻改成 xfs 文件系统了。
另外，由于虚拟化的应用越来越广泛，而作为虚拟化磁盘来源的巨型文件 （单一文件好几个 GB 以上！） 也就越来越常见了。 这种巨型文件在处理上需要考虑到性能问题，否则虚拟磁盘的效率就会不太好看。因此，从 CentOS 7.x 开始， 文件系统已经由默认的 Ext4 变成了 xfs 这一个较适合大容量磁盘与巨型文件性能较佳的文件系统了。
Tips 其实鸟哥有几组虚拟计算机教室服务器系统，里面跑的确实是 EXT4 文件系统，老实说，并不觉得比 xfs 慢！所以，对鸟哥来说， 性能并不是主要改变文件系统的考虑！对于文件系统的复原速度、创建速度，可能才是鸟哥改换成 xfs 的思考点。
XFS 文件系统的配置 [6]基本上 xfs 就是一个日志式文件系统，而 CentOS 7.x 拿它当默认的文件系统，自然就是因为最早之前，这个 xfs 就是被开发来用于大容量磁盘以及高性能文件系统之用， 因此，相当适合现在的系统环境。此外，几乎所有 Ext4 文件系统有的功能， xfs 都可以具备！也因此在本小节前几部份谈到文件系统时， 其实大部份的操作依旧是在 xfs 文件系统环境下介绍给各位的哩！
xfs 文件系统在数据的分佈上，主要规划为三个部份，一个数据区 （data section）、一个文件系统活动登录区 （log section）以及一个实时运行区 （realtime section）。 这三个区域的数据内容如下：
数据区 （data section）基本上，数据区就跟我们之前谈到的 ext 家族一样，包括 inode/data block/superblock 等数据，都放置在这个区块。 这个数据区与 ext 家族的 block group 类似，也是分为多个储存区群组 （allocation groups） 来分别放置文件系统所需要的数据。 每个储存区群组都包含了 （1）整个文件系统的 superblock、 （2）剩余空间的管理机制、 （3）inode的分配与追踪。此外，inode与 block 都是系统需要用到时， 这才动态配置产生，所以格式化动作超级快！
另外，与 ext 家族不同的是， xfs 的 block 与 inode 有多种不同的容量可供设置，block 容量可由 512Bytes ~ 64K 调配，不过，Linux 的环境下， 由于内存控制的关系 （分页档 pagesize 的容量之故），因此最高可以使用的 block 大小为 4K 而已！（鸟哥尝试格式化 block 成为 16K 是没问题的，不过，Linux 核心不给挂载！ 所以格式化完成后也无法使用啦！） 至于 inode 容量可由 256Bytes 到 2M 这么大！不过，大概还是保留 256Bytes 的默认值就很够用了！
Tips 总之， xfs 的这个数据区的储存区群组 （allocation groups, AG），你就将它想成是 ext 家族的 block 群组 （block groups） 就对了！本小节之前讲的都可以在这个区块内使用。 只是 inode 与 block 是动态产生，并非一开始于格式化就完成配置的。
文件系统活动登录区 （log section）在登录区这个区域主要被用来纪录文件系统的变化，其实有点像是日志区啦！文件的变化会在这里纪录下来，直到该变化完整的写入到数据区后， 该笔纪录才会被终结。如果文件系统因为某些缘故 （例如最常见的停电） 而损毁时，系统会拿这个登录区块来进行检验，看看系统挂掉之前， 文件系统正在运行些啥动作，借以快速的修复文件系统。
因为系统所有动作的时候都会在这个区块做个纪录，因此这个区块的磁盘活动是相当频繁的！xfs 设计有点有趣，在这个区域中， 你可以指定外部的磁盘来作为 xfs 文件系统的日志区块喔！例如，你可以将 SSD 磁盘作为 xfs 的登录区，这样当系统需要进行任何活动时， 就可以更快速的进行工作！相当有趣！
实时运行区 （realtime section）当有文件要被创建时，xfs 会在这个区段里面找一个到数个的 extent 区块，将文件放置在这个区块内，等到分配完毕后，再写入到 data section 的 inode 与 block 去！ 这个 extent 区块的大小得要在格式化的时候就先指定，最小值是 4K 最大可到 1G。一般非磁盘阵列的磁盘默认为 64K 容量，而具有类似磁盘阵列的 stripe 情况下，则建议 extent 设置为与 stripe 一样大较佳。这个 extent 最好不要乱动，因为可能会影响到实体磁盘的性能喔。
XFS 文件系统的描述数据观察刚刚讲了这么多，完全无法理会耶～有没有像 EXT 家族的 dumpe2fs 去观察 superblock 内容的相关指令可以查阅呢？有啦！可以使用 xfs_info 去观察的！ 详细的指令作法可以参考如下：
[root@study ~]# xfs_info 挂载点|设备文件名 范例一：找出系统 /boot 这个挂载点下面的文件系统的 superblock 纪录 [root@study ~]# df -T /boot Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/vda2 xfs 1038336 133704 904632 13% /boot # 没错！可以看得出来是 xfs 文件系统的！来观察一下内容吧！ [root@study ~]# xfs_info /dev/vda2 1 meta-data=/dev/vda2 isize=256 agcount=4, agsize=65536 blks 2 = sectsz=512 attr=2, projid32bit=1 3 = crc=0 finobt=0 4 data = bsize=4096 blocks=262144, imaxpct=25 5 = sunit=0 swidth=0 blks 6 naming =version 2 bsize=4096 ascii-ci=0 ftype=0 7 log =internal bsize=4096 blocks=2560, version=2 8 = sectsz=512 sunit=0 blks, lazy-count=1 9 realtime =none extsz=4096 blocks=0, rtextents=0上面的输出讯息可以这样解释：
第 1 行里面的 isize 指的是 inode 的容量，每个有 256Bytes 这么大。至于 agcount 则是前面谈到的储存区群组 （allocation group） 的个数，共有 4 个， agsize 则是指每个储存区群组具有 65536 个 block 。配合第 4 行的 block 设置为 4K，因此整个文件系统的容量应该就是 4655364K 这么大！第 2 行里面 sectsz 指的是逻辑扇区 （sector） 的容量设置为 512Bytes 这么大的意思。第 4 行里面的 bsize 指的是 block 的容量，每个 block 为 4K 的意思，共有 262144 个 block 在这个文件系统内。第 5 行里面的 sunit 与 swidth 与磁盘阵列的 stripe 相关性较高。这部份我们下面格式化的时候会举一个例子来说明。第 7 行里面的 internal 指的是这个登录区的位置在文件系统内，而不是外部设备的意思。且占用了 4K * 2560 个 block，总共约 10M 的容量。第 9 行里面的 realtime 区域，里面的 extent 容量为 4K。不过目前没有使用。由于我们并没有使用磁盘阵列，因此上头这个设备里头的 sunit 与 extent 就没有额外的指定特别的值。根据 xfs（5） 的说明，这两个值会影响到你的文件系统性能， 所以格式化的时候要特别留意喔！上面的说明大致上看看即可，比较重要的部份已经用特殊字体圈起来，你可以瞧一瞧先！
https://www.ibm.com/developerworks/cn/linux/theme/filesystem.html
转载于:https://www.cnblogs.com/liujiacai/p/8280713.html
