Linux日志式文件系统面面观 Posted 2023-04-05
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Linux日志式文件系统面面观相关的知识，希望对你有一定的参考价值。
参考技术A
文件系统是用来管理和组织保存在磁盘驱动器上的数据的系统软件，其实现了数据完整性的保 证，也就是保证写入磁盘的数据和随后读出的内容的一致性。除了保存以文件方式存储的数据以外，一个文件系统同样存储和管理关于文件和文件系统自身的一些重要信息(例如：日期时间、属主、访问权限、文件大小和存储位置等等)。这些信息通常被称为元数据(metadata)。
由于为了避免磁盘访问瓶颈效应，一般文件系统大都以异步方式工作，因此如果磁盘操作被突然中断可能导致数据被丢失。例如如果出现这种情况：如果当你处理一个在linux的ext2文件系统上的文档，突然机器崩溃会出现什么情况？
有这几种可能：
*当你保存文件以后，系统崩溃。这是最好的情况，你不会丢失任何信息。只需要重新启动计算机然后继续工作。
*在你保存文件之前系统崩溃。你会丢失你所有的工作内容，但是老版本的文档还会存在。
*当正在将保存的文档写入磁盘时系统崩溃。这是最糟的情况：新版文件覆盖了旧版本的文件。这样磁盘上只剩下一个部分新部分旧的文件。如果文件是二进制文件那么就会出现不能打开文件的情况，因为其文件格式和应用所期待的不同。
在最后这种情况下，如果系统崩溃是发生在驱动器正在写入元数据时，那么情况可能更糟。这时候就是文件系统发生了损坏，你可能会丢失整个目录或者整个磁盘分区的数据。
linux标准文件系统(ext2fs)在重新启动时会通过调用文件扫描工具fsck试图恢复损坏的元数据信息。由于ext2文件系统保存有冗余的关键元数据信息的备份，因此一般来说不大可能出现数据完全丢失。系统会计算出被损坏的数据的位置，然后或者是通过恢复冗余的元数据信息，或者是直接删除被损坏或是元数据信息损毁的文件。
很明显，要检测的文件系统越大，检测过程费时就越长。对于有几十个G大小的分区，可能会花费很长时间来进行检测。由于Linux开始用于大型服务器中越来越重要的应用，因此就越来越不能容忍长时间的当机时间。这就需要更复杂和精巧的文件系统来替代ext2。
因此就出现了日志式文件系统(journalling filesystems)来满足这样的需求。
什么是日志式文件系统
这里仅仅对日志式文件系统进行简单的说明。如果需要更深入的信息请参考文章日志式文件系统，或者是日志式文件系统介绍。
大多数现代文件系统都使用了来自于数据库系统中为了提高崩溃恢复能力而开发的日志技术。磁盘事务在被真正写入到磁盘的最终位置以前首先按照顺序方式写入磁盘中日志区(或是log区)的特定位置。
根据日志文件系统实现技术的不同，写入日志区的信息是不完全一样的。某些实现技术仅仅写文件系统元数据，而其他则会记录所有的写操作到日志中。
现在，如果崩溃发生在日志内容被写入之前发生，那么原始数据仍然在磁盘上，丢失的仅仅是最新的更新内容。如果当崩溃发生在真正的写操作时(也就是日志内容已经更新)，日志文件系统的日志内容则会显示进行了哪些操作。因此当系统重启时，它能轻易根据日志内容，很快地恢复被破坏的更新。
在任何一种情况下，都会得到完整的数据，不会出现损坏的分区的情况。由于恢复过程根据日志进行，因此整个过程会非常快只需要几秒钟时间。
应该注意的是使用日志文件系统并不意味着完全不需要使用文件扫描工具fsck了。随机发生的文件系统的硬件和软件错误是根据日志是无法恢复的，必须借助于fsck工具。
目前Linux环境下的日志文件系统
在下面的内容里将讨论三种日志文件系统：第一种是ext3，由Linux内核Stephen Tweedie开发。ext3是通过向ext2文件系统上添加日志功能来实现的，目前是redhat7.2的默认文件系统；Namesys开发的ReiserFs日志式文件系统，可以下载，目前Mandrake8.1采用该日志式文件系统。SGI在2001年三月发布了XFS日志式文件系统。可以在 oss.sgi.com/projects/xfs/下载。下面将对这三种日志文件系统采用不同的工具进行检测和性能测试。
安装ext3
关于ext3文件系统技术方面的问题请参考Dr. Stephen Tweedie的论文和访谈。ext3日志式文件系统直接来自于其祖先ext2文件系统。其具有完全向后兼容的关键特性，实际上其仅仅是在ext2日志式文件系统上添加了日志功能。其最大的缺点是没有现代文件系统所具有的能提高文件数据处理速度和解压的高性能。
ext3从 2.2.19开始是作为一个补丁方式存在的。如果希望对内核添加对ext3文件系统的支持，就需要使用补丁，可以得到补丁程序，一共需要如下文件：
* ext3-0.0.7a.tar.bz2：内核补丁
* e2fsprogs-1.21-WIP-0601.tar.bz2 支持ext3的e2fsprogs程序套件
拷贝linux-2.2.19.tar.bz2和ext3-0.0.7a.tar.bz2到/usr/src目录下，进行解压：
mv linux linux-old
tar -Ixvf linux-2.2.19.tar.bz2
tar -Ixvf ext3-0.0.7a.tar.bz2
cd linux
cat ../ext3-0.0.7a/linux-2.2.19.kdb.diff | patch -sp1
cat ../ext3-0.0.7a/linux-2.2.19.ext3.diff | patch -sp1
首先对内核添加SGI的kdb内核调试器补丁，第二个是ext3文件系统补丁。下来就需要配置内核，对文件系统部分的"Enable Second extended fs development code"回答Yes。然后编译。
内核编译安装以后，需要安装e2fsprogs软件套件：
tar -Ixvf e2fsprogs-1.21-WIP-0601.tar.bz2
cd e2fsprogs-1.21
./configure
make
make check
make install
下来要做的工作就是在分区上创建一个ext3文件系统，使用新内核重新启动，这时候你有两种选择创建新的日志文件系统或者对一个已有的ext2文件系统升级到ext3日志文件系统。
对于需要创建新ext3文件系统的情况下，只需要使用安装的e2fsprogs软件包中的mke2fs命令加-f参数就可以创建新的ext3文件系统：
mke2fs -j /dev/xxx
这里/dev/xxx是希望创建ext3文件系统的新分区。-j参数表示创建ext3而不是ext2文件系统。可以使用参数"-Jsize="来指定希望的日志区大小(n单位为M)。
升级一个已有的ext2，使用tune2fs就可以了：
tune2fs -j /dev/xxx
你可以对正在加载的文件系统和没有加载的文件系统进行升级操作。如果当前文件系统正在被加载，则文件.journal会在文件系统加载点的所在目录被创建。如果是升级一个当时没有加载的文件系统，则使用隐含的系统inode来记录日志，这时候文件系统的所有内容都会被保留不被破坏。
你可以使用下面的命令加载ext3文件系统：
mount -t ext3 /dev/xxx /mount_dir
由于ext3实际上是带有日志功能的ext2文件系统 ，因此一个ext3文件系统可以以ext2的方式被加载。
安装XFS文件系统
如果需要从技术方面了解XFS文件系统，请参考SGI的XFS文件系统和SGI信息页面。也可以参考FAQ。
XFS是一个SGI开发的linux环境下的日志文件系统，它是一个成熟的技术，最初是使用在IRIX系统上的文件系统。XFS遵循GPL版权申明。目前xfs文件系统最新版本是1.02。下载得到对内核xfs文件系统支持补丁或者直接下载RPM包方式的内核，下面我们就以补丁方式说明如何对2.4.14内核使用xfs。首先下载如下内容
patch-2.4.14-xfs-1.0.2.bz2
patch-2.4.14-xfs-1.0.2-kdb.bz2
拷贝Linux内核linux-2.4.2.tar.bz2到 /usr/src目录下，修改老的内核目录名，然后解压新内核：
mv linux linux-old
tar -Ixf inux-2.4.2.tar.bz2
拷贝每个每个补丁到内核源码目录下(例如：/usr/src/linux)，并打补丁：
zcat patch-2.4.14-xfs-1.0.2.bz2 | patch -p1
zcat patch-2.4.14-xfs-1.0.2-kdb.bz2 | patch -p1
然后配置内核，打开文件系统部分的内核选项："XFS filesystem support" (CONFIG_XFS_FS)和"Page Buffer support" (CONFIG_PAGE_BUF)。同时需要升级下面这些系统工具到下面或更高的版本：
modutils-2.4.0
autoconf-2.13
e2fsprogs-devel-1.18
安装新内核并重启服务器。
然后下载xfs工具。这个软件包包括下面的命令来处理文件系统，使用下面的命令来安装该软件包：：
tar -zxf xfsprogs-1.2.0.src.tar.gz
cd xfsprogs-1.2.0
make configure
make
make install
安装这些命令以后，就可以创建新的XFS文件系统：
mkfs -t xfs /dev/xxx
如果xxx是一个已经存在的文件系统，那么就需要使用"-f"参数来创建新分区，但是记得这将会破坏该分区的所有数据。
mkfs -t xfs -f /dev/xxx
创建以后就可以使用基于下面的命令加载新文件系统：
mount -t xfs /dev/xxx /mount_dir
安装ReiserFS文件系统
如果希望更多地从技术方面了解reiserFS文件系统，请参考NAMESYS和FAQ。
ReiserFS文件系统从2.4.1-pre4开始就是Linux内核的正式支持的文件系统了。为了使用reiserFS文件系统那你首先需要在系统上安装文件系统支持工具(如：创建ReiserFS文件系统的mkreiserfs工具)。最新的ReiserFS文件系统版本可以以补丁的方式添加到2.2.x或者2.4.x内核中。这里我们以2.2.19为例：
第一步，首先下在内核源码，并下在ReiserFS文件系统的2.2.19补丁 ，目前补丁最新版本是linux-2.2.19-reiserfs-3.5.34-patch.bz2。同时应该下载工具软件包：reiserfsprogs-3.x.0j.tar.gz。
然后解压内核源码和补丁包到/usr/src中：
tar -Ixf linux-2.2.19.tar.bz2
bzcat linux-2.2.19-reiserfs-3.5.34-patch.bz2 | patch -p0
编译内核支持reiserfs，安装内核。然后安装文件系统工具软件：
cd /usr/src/linux/fs/reiserfs/utils
make
make install
安装新内核并重新启动。现在就可以创建新的\'reiserfs文件系统，并加载：
mkreiserfs /dev/xxxx
mount -t reiserfs /dev/xxx /mount_dir
文件系统性能测试
测试环境使用的计算机环境如下：Pentium III - 16 Mb RAM - 2 Gb HD，操作系统为RedHat6.2。所有的文件系统都能正常工作，所以就进行benchmark分析来对它们进行性能比较。首先我直接拔掉系统电源以模拟系统掉电情况，以测试日志文件系统恢复过程。所有的文件系统都成功地经过了文件扫描检测阶段，在数秒以后系统都经过了扫描然后正常启动了系统。
下一步就采用了bonnie++性能测试程序进行测试，这个程序对一个文件进行数据库类型的访问，进行了创建、读和删除小文件，这些操作对于Squid、INN或者Maildir格式的邮件服务器程序(qmail)是最常见的操作。性能测试命令为：
bonnie++ -d/work1 -s10 -r4 -u0
其对加载在/work1目录下的文件系统进行了10Mb(-s10)的测试。因此在执行测试之前必须创建适当类型的文件系统并加载到目录/work1下。其他的参数指定内存大小(-r4)的M数，和以root身份运行测试程序，测试结果如下：
每种测试都有两组数据：文件系统速度(K/sec)和CPU占用率(%CPU)。速度越高，文件系统越好。而对于CPU率来说，数字越小性能越好。可以看到Reiserfs文件系统在文件操作方面(Sequential Create和Random Create部分的) 的性能最好，超出其他文件系统10倍之多。在其他方面(Sequential Output和Sequential Input)则和其他文件系统性能不相上下。对于其他文件系统则没有特别明显的区别。XFS性能接近ext2文件系统，ext3文件系统则比ext2要稍微慢上一些(因为记录日志需要一些额外的时间)。 最后使用从得到的性能测试程序mongo，并对其进行了修改以对三种日志文件系统进行测试。这里在mongo.pl程序中添加了添加了加载xfs和ext3文件系统的命令，并对其进行格式化处理，然后就开始性能测试分析。 该脚本格式划分区/dev/xxxx，加载其并在每个阶段运行指定数目的进程：创建、拷贝、符号连接处理、读、显示文件状态信息、重命名和删除文件。同时，该程序在创建和拷贝阶段以后会计算分段数(fragmentation)。
Fragm = number_of_fragments / number_of_files
可以在结果文件中得到同样的测试比较结果：
log - 原始结果
log.tbl - 比较程序的输出结果
log_table - 表格式的结果
下面的命令进行测试：
mongo.pl ext3 /dev/hda3 /work1 logext3 1
如果要测试其他文件系统，就需要把上面命令的参数中的ext3修改为reiserfs或xfs。其他参数分别为要加载的分区，加载路径，保存测试结果的文件名及启动的进程数。
下面的表格是测试结果。数据单位为秒。值越低性能越好。第一个表格测试使用的数据块大小为100字节，第二个表格为1000字节，最后一个为10000字节
从上面的表格可以看到ext3在状态删除和重命名方面要性能更好一些，而ReiserFS文件系统在文件创建和拷贝性能表现更出色。同时也可以看到reiserFS正如其技术文档提到的其在小文件处理方面性能相当出色。
结论
目前Linux至少有两个健壮可靠的日志文件系统可供选择(XFS和reiserFS)，其都得到了广泛的应用。例如Mandrake8.1就默认支持reiserFS文件系统。
从性能测试的结果可以看到，reiserFS是最好的选择。
第八章Linux 磁盘与文件系统管理
1. 认识 EXT2 文件系统
1.1硬盘组成与分割的复习
1.2.文件系统特性
传统的磁盘与文件系统之应用中，一个分割槽就是只能够被格式化成为一个文件系统，所以我们可以说一个 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
1.索引式文件系统(indexed allocation)
由于每个 inode 与 block 都有编号，而每个文件都会占用一个 inode ，inode 内则有文件数据放置的 block 号码。 因此，我们可以知道的是，如果能够找到文件的 inode 的话，那么自然就会知道这个文件所放置数据的 block 号码， 当然也就能够读出该文件的实际数据了。这是个比较有效率的作法，因为如此一来我们的磁盘就能够在短时间内读取出全部的数据， 读写的效能比较好啰。
2.FAT
那有没有其他的惯用文件系统可以比较一下啊？ 有的，那就是我们惯用的闪盘(闪存)，闪盘使用的文件系统一般为 FAT 格式。FAT 这种格式的文件系统并没有 inode 存在，所以 FAT 没有办法将这个文件的所有 block 在一开始就读取出来。每个 block 号码都记录在前一个 block 当中， 他的读取方式有点像底下这样：
3.总结
常常会听到所谓的『碎片整理』吧？ 需要碎片整理的原因就是文件写入的 block 太过于离散了，此时文件读取的效能将会变的很差所致。 这个时候可以透过碎片整理将同一个文件所属的 blocks 汇整在一起，这样数据的读取会比较容易啊！ 想当然尔，FAT 的文件系统需要经常的碎片整理一下，那么 Ext2 是否需要磁盘重整呢？
由于 Ext2 是索引式文件系统，基本上不太需要常常进行碎片整理的。但是如果文件系统使用太久， 常常删除/编辑/新增文件时，那么还是可能会造成文件数据太过于离散的问题，此时或许会需要进行重整一下的。 不过，老实说，鸟哥倒是没有在 Linux 操作系统上面进行过 Ext2/Ext3 文件系统的碎片整理说！似乎不太需要啦！^_^
1.3.Linux 的 EXT2 文件系统(inode)：
1.data block (数据区块)
data block 是用来放置文件内容数据地方，在 Ext2 文件系统中所支持的 block 大小有 1K, 2K 及 4K 三种而已
由于 block 大小的差异，会导致该文件系统能够支持的最大磁盘容量与最大单一文件容量并不相同。 因为 block 大小而产生的 Ext2 文件系统限制如下
除此之外 Ext2 文件系统的 block 还有什么限制呢？有的！基本限制如下：
原则上，block 的大小与数量在格式化完就不能够再改变了(除非重新格式化)；
每个 block 内最多只能够放置一个文件的数据；
承上，如果文件大于 block 的大小，则一个文件会占用多个 block 数量；
承上，若文件小于 block ，则该 block 的剩余容量就不能够再被使用了(磁盘空间会浪费)。
既然大的 block 可能会产生较严重的磁盘容量浪费，那么我们是否就将 block 大小订为 1K 即可？ 这也不妥，因为如果 block 较小的话，那么大型文件将会占用数量更多的 block ，而 inode 也要记录更多的 block 号码，此时将可能导致文件系统不良的读写效能。
2.inode table (inode 表格)
inode 记录的文件数据至少有底下这些
该文件的存取模式(read/write/excute)；
该文件的拥有者与群组(owner/group)；
该文件的容量；
该文件创建或状态改变的时间(ctime)；
最近一次的读取时间(atime)；
最近修改的时间(mtime)；
定义文件特性的旗标(flag)，如 SetUID...；
该文件真正内容的指向 (pointer)；
inode 的数量与大小也是在格式化时就已经固定了，除此之外 inode 还有些什么特色呢？
每个 inode 大小均固定为 128 bytes；
每个文件都仅会占用一个 inode 而已；
承上，因此文件系统能够创建的文件数量与 inode 的数量有关；
系统读取文件时需要先找到 inode，并分析 inode 所记录的权限与用户是否符合，若符合才能够开始实际读取 block 的内容
我们约略来分析一下 inode / block 与文件大小的关系好了。inode 要记录的数据非常多，但偏偏又只有 128bytes 而已， 而 inode 记录一个 block 号码要花掉 4byte ，假设我一个文件有 400MB 且每个 block 为 4K 时， 那么至少也要十万笔 block 号码的记录呢！inode 哪有这么多可记录的信息？为此我们的系统很聪明的将 inode 记录 block 号码的区域定义为12个直接，一个间接, 一个双间接与一个三间接记录区。这是啥？我们将 inode 的结构画一下好了。
这样子 inode 能够指定多少个 block 呢？我们以较小的 1K block 来说明好了，可以指定的情况如下：
由于是直接指向，所以总共可记录 12 笔记录，因此总额大小为如上所示；
每笔 block 号码的记录会花去 4bytes，因此 1K 的大小能够记录 256 笔记录，因此一个间接可以记录的文件大小如上；
第一层 block 会指定 256 个第二层，每个第二层可以指定 256 个号码，因此总额大小如上；
三间接： 256*256*256*1K=2563K
第一层 block 会指定 256 个第二层，每个第二层可以指定 256 个第三层，每个第三层可以指定 256 个号码，因此总额大小如上；
总额：将直接、间接、双间接、三间接加总，得到 12 + 256 + 256*256 + 256*256*256 (K) = 16GB
此时我们知道当文件系统将 block 格式化为 1K 大小时，能够容纳的最大文件为 16GB，比较一下
文件系统限制表 的结果可发现是一致的！
但这个方法不能用在 2K 及 4K block 大小的计算中， 因为大于 2K 的 block 将会受到 Ext2 文件系统本身的限制，所以计算的结果会不太符合之故。
3.Superblock (超级区块)
Superblock 是记录整个 filesystem 相关信息的地方， 没有 Superblock ，就没有这个 filesystem 了。他记录的信息主要有：
block 与 inode 的总量；
未使用与已使用的 inode / block 数量；
block 与 inode 的大小 (block 为 1, 2, 4K，inode 为 128 bytes)；
filesystem 的挂载时间、最近一次写入数据的时间、最近一次检验磁盘 (fsck) 的时间等文件系统的相关信息；
一个 valid bit 数值，若此文件系统已被挂载，则 valid bit 为 0 ，若未被挂载，则 valid bit 为 1 。
4.Filesystem Description (文件系统描述说明)
5.block bitmap (区块对照表)
6.inode bitmap (inode 对照表)
7.dumpe2fs
1.4.与目录树的关系
由前一小节的介绍我们知道在 Linux 系统下，每个文件(不管是一般文件还是目录文件)都会占用一个 inode ， 且可依据文件内容的大小来分配多个 block 给该文件使用。而由
第六章的权限说明 中我们知道目录的内容在记录文件名， 一般文件才是实际记录数据内容的地方。那么目录与文件在 Ext2 文件系统当中是如何记录数据的呢？ 基本上可以这样说：
1.目录
当我们在 Linux 下的 ext2 文件系统创建一个目录时， ext2 会分配一个 inode 与至少一块 block 给该目录。其中，inode 记录该目录的相关权限与属性，并可记录分配到的那块 block 号码； 而 block 则是记录在这个目录下的文件名与该文件名占用的 inode 号码数据。
如果想要实际观察 root 家目录内的文件所占用的 inode 号码时，可以使用 ls -i 这个选项来处理：
2.文件：
当我们在 Linux 下的 ext2 创建一个一般文件时， ext2 会分配一个 inode 与相对于该文件大小的 block 数量给该文件。例如：假设我的一个 block 为 4 Kbytes ，而我要创建一个 100 KBytes 的文件，那么 linux 将分配一个 inode 与 25 个 block 来储存该文件！ 但同时请注意，由于 inode 仅有 12 个直接指向，因此还要多一个 block 来作为区块号码的记录喔！
3.目录树读取：
经过上面的说明你也应该要很清楚的知道
inode 本身并不记录文件名，文件名的记录是在目录的 block 当中。 因此在第六章文件与目录的权限 我们才会提到『新增/删除/更名文件名与目录的 w 权限有关』的特色！那么因为文件名是记录在目录的 block 当中， 因此当我们要读取某个文件时，就务必会经过目录的 inode 与 block ，然后才能够找到那个待读取文件的 inode 号码， 最终才会读到正确的文件的 block 内的数据。
由于目录树是由根目录开始读起，因此系统透过挂载的信息可以找到挂载点的 inode 号码(通常一个 filesystem 的最顶层 inode 号码会由 2 号开始喔！)，此时就能够得到根目录的 inode 内容，并依据该 inode 读取根目录的 block 内的文件名数据，再一层一层的往下读到正确的档名。
在鸟哥的系统上面与 /etc/passwd 有关的目录与文件数据如上表所示，该文件的读取流程为(假设读取者身份为 vbird 这个一般身份使用者)：
/ 的 inode：
4.filesystem 大小与磁盘读取效能：
1.4 EXT2/EXT3 文件的存取与日志式文件系统的功能
上一小节谈到的仅是读取而已，那么如果是新建一个文件或目录时，我们的 Ext2 是如何处理的呢？ 这个时候就得要 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 的数据是经常变动的，每次新增、移除、编辑时都可能会影响到这三个部分的数据，因此才被称为中介数据的啦
1.数据的不一致 (Inconsistent) 状态
2.日志式文件系统 (Journaling filesystem)
为了避免上述提到的文件系统不一致的情况发生，因此我们的前辈们想到一个方式， 如果在我们的 filesystem 当中规划出一个区块，该区块专门在记录写入或修订文件时的步骤， 那不就可以简化一致性检查的步骤了？也就是说：
预备：当系统要写入一个文件时，会先在日志记录区块中纪录某个文件准备要写入的信息；
实际写入：开始写入文件的权限与数据；开始升级 metadata 的数据；
结束：完成数据与 metadata 的升级后，在日志记录区块当中完成该文件的纪录
那么我们的
ext2 可达到这样的功能吗？当然可以啊！ 就透过 ext3 即可！ ext3 是 ext2 的升级版本，并且可向下兼容 ext2 版本呢！ 所以啰，目前我们才建议大家，可以直接使用 ext3 这个 filesystem 啊！ 如果你还记得 dumpe2fs
1.5Linux 文件系统的运行：
我们现在知道了目录树与文件系统的关系了，但是由
第零章 的内容我们也知道， 所有的数据都得要加载到内存后 CPU 才能够对该数据进行处理。想一想，如果你常常编辑一个好大的文件， 在编辑的过程中又频繁的要系统来写入到磁盘中，由于磁盘写入的速度要比内存慢很多， 因此你会常常耗在等待硬盘的写入/读取上。真没效率！
我们的 Linux 使用的方式是透过一个称为异步处理 (asynchronously) 的方式。所谓的异步处理是这样的：
当系统加载一个文件到内存后，如果该文件没有被更动过，则在内存区段的文件数据会被配置为干净(clean)的。 但如果内存中的文件数据被更改过了(例如你用 nano 去编辑过这个文件)，此时该内存中的数据会被配置为脏的 (Dirty)。此时所有的动作都还在内存中运行，并没有写入到磁盘中！ 系统会不定时的将内存中配置为『Dirty』的数据写回磁盘，以保持磁盘与内存数据的一致性。 你也可以利用
第五章谈到的 sync 命令来手动强迫写入磁盘。
因此我们 Linux 系统上面文件系统与内存有非常大的关系喔：
系统会将常用的文件数据放置到主存储器的缓冲区，以加速文件系统的读/写；
承上，因此 Linux 的物理内存最后都会被用光！这是正常的情况！可加速系统效能；
你可以手动使用 sync 来强迫内存中配置为 Dirty 的文件回写到磁盘中；
若正常关机时，关机命令会主动呼叫 sync 来将内存的数据回写入磁盘内；
但若不正常关机(如跳电、死机或其他不明原因)，由于数据尚未回写到磁盘内， 因此重新启动后可能会花很多时间在进行磁盘检验，甚至可能导致文件系统的损毁(非磁盘损毁)。
1.6挂载点的意义 (mount point)：
每个 filesystem 都有独立的 inode / block / superblock 等信息，这个文件系统要能够链接到目录树才能被我们使用。 将文件系统与目录树结合的动作我们称为『挂载』。
重点是：挂载点一定是目录，该目录为进入该文件系统的入口。 因此并不是你有任何文件系统都能使用，必须要『挂载』到目录树的某个目录后，才能够使用该文件系统的。
举例来说，如果你是依据鸟哥的方法
安装你的 CentOS 5.x 的话，
那么应该会有三个挂载点才是，分别是 /, /boot, /home 三个 (鸟哥的系统上对应的装置文件名为 /dev/hdc2, /dev/hdc1, /dev/hdc3)。 那如果观察这三个目录的 inode 号码时，我们可以发现如下的情况： 看到了吧！由于 filesystem 最顶层的目录之 inode 一般为 2 号，因此可以发现 /, /boot, /home 为三个不同的 filesystem 啰！ (因为每一行的文件属性并不相同，且三个目录的挂载点也均不相同之故。)
. 与 .. 是相同的东西， 因为权限是一模一样嘛！如果使用文件系统的观点来看，同一个 filesystem 的某个 inode 只会对应到一个文件内容而已(因为一个文件占用一个 inode 之故)， 因此我们可以透过判断 inode 号码来确认不同文件名是否为相同的文件喔！所以可以这样看：
上面的信息中由于挂载点均为 / ，因此三个文件 (/, /., /..) 均在同一个 filesystem 内，而这三个文件的 inode 号码均为 2 号，因此这三个档名都指向同一个 inode 号码，当然这三个文件的内容也就完全一模一样了！ 也就是说，根目录的上一级 (/..) 就是他自己！这么说，看的懂了吗？ ^_^
1.7其他 Linux 支持的文件系统与 VFS
虽然 Linux 的标准文件系统是 ext2 ，且还有添加了日志功能的 ext3 ，事实上，Linux 还有支持很多文件系统格式的， 尤其是最近这几年推出了好几种速度很快的日志式文件系统，包括 SGI 的 XFS 文件系统， 可以适用更小型文件的 Reiserfs 文件系统，以及 Windows 的 FAT 文件系统等等， 都能够被 Linux 所支持喔！常见的支持文件系统有：
传统文件系统：ext2 / minix / MS-DOS / FAT (用 vfat 模块) / iso9660 (光盘)等等； 日志式文件系统： ext3 / ReiserFS / Windows‘ NTFS / IBM‘s JFS / SGI‘s XFS 网络文件系统： NFS / SMBFS
要知道你的 Linux 支持的文件系统有哪些，可以察看底下这个目录：
系统目前已加载到内存中支持的文件系统则有：
1.Linux VFS (Virtual Filesystem Switch)
其实，整个 Linux 的系统都是透过一个名为 Virtual Filesystem Switch 的核心功能去读取 filesystem 的。 也就是说，整个 Linux 认识的 filesystem 其实都是 VFS 在进行管理
假设你的 / 使用的是 /dev/hda1 ，用 ext3 ，而 /home 使用 /dev/hda2 ，用 reiserfs ， 那么你取用 /home/dmtsai/.bashrc 时，有特别指定要用的什么文件系统的模块来读取吗？ 应该是没有吧！这个就是 VFS 的功能啦！透过这个 VFS 的功能来管理所有的 filesystem， 省去我们需要自行配置读取文件系统的定义啊～方便很多！整个 VFS 可以约略用下图来说明：
2. 文件系统的简单操作
2.1 磁盘与目录的容量： df, du
现在我们知道磁盘的整体数据是在 superblock 区块中，但是每个各别文件的容量则在 inode 当中记载的。 那在文字接口底下该如何叫出这几个数据呢？底下就让我们来谈一谈这两个命令：
df：列出文件系统的整体磁盘使用量；
du：评估文件系统的磁盘使用量(常用在推估目录所占容量)
df
先来说明一下范例一所输出的结果信息为：
Filesystem：代表该文件系统是在哪个 partition ，所以列出装置名称；
1k-blocks：说明底下的数字单位是 1KB 呦！可利用 -h 或 -m 来改变容量；
Used：顾名思义，就是使用掉的硬盘空间啦！
Available：也就是剩下的磁盘空间大小；
Use%：就是磁盘的使用率啦！如果使用率高达 90% 以上时， 最好需要注意一下了，免得容量不足造成系统问题喔！(例如最容易被灌爆的 /var/spool/mail 这个放置邮件的磁盘)
Mounted on：就是磁盘挂载的目录所在啦！(挂载点啦！)
du
与 df 不一样的是，du 这个命令其实会直接到文件系统内去搜寻所有的文件数据， 所以上述第三个范例命令的运行会运行一小段时间！此外，在默认的情况下，容量的输出是以 KB 来设计的， 如果你想要知道目录占了多少 MB ，那么就使用 -m 这个参数即可啰！而， 如果你只想要知道该目录占了多少容量的话，使用 -s 就可以啦！
至于 -S 这个选项部分，由于 du 默认会将所有文件的大小均列出，因此假设你在 /etc 底下使用 du 时， 所有的文件大小，包括 /etc 底下的次目录容量也会被计算一次。然后最终的容量 (/etc) 也会加总一次， 因此很多朋友都会误会 du 分析的结果不太对劲。所以啰，如果想要列出某目录下的全部数据， 或许也可以加上 -S 的选项，减少次目录的加总喔！
2.2 实体链接与符号链接： ln
在 Linux 底下的连结档有两种，一种是类似 Windows 的快捷方式功能的文件，可以让你快速的链接到目标文件(或目录)； 另一种则是透过文件系统的 inode 连结来产生新档名，而不是产生新文件！这种称为实体链接 (hard link)。 这两种玩意儿是完全不一样的东西呢！现在就分别来谈谈。
1.Hard Link (实体链接, 硬式连结或实际连结)
在前一小节当中，我们知道几件重要的信息，包括：
每个文件都会占用一个 inode ，文件内容由 inode 的记录来指向；
想要读取该文件，必须要经过目录记录的文件名来指向到正确的 inode 号码才能读取。
也就是说，其实文件名只与目录有关，但是文件内容则与 inode 有关。那么想一想， 有没有可能有多个档名对应到同一个 inode 号码呢？有的！那就是 hard link 的由来。 所以简单的说：hard link 只是在某个目录下新增一笔档名链接到某 inode 号码的关连记录而已。
举个例子来说，假设我系统有个 /root/crontab 他是 /etc/crontab 的实体链接，也就是说这两个档名连结到同一个 inode ， 自然这两个文件名的所有相关信息都会一模一样(除了文件名之外)。实际的情况可以如下所示：
你可以发现两个档名都连结到 1912701 这个 inode 号码，所以您瞧瞧，是否文件的权限/属性完全一样呢？ 因为这两个『档名』其实是一模一样的『文件』啦！而且你也会发现第二个字段由原本的 1 变成 2 了！ 那个字段称为『连结』，这个字段的意义为：『有多少个档名链接到这个 inode 号码』的意思。 如果将读取到正确数据的方式画成示意图，就类似如下画面：
上图的意思是，你可以透过 1 或 2 的目录之 inode 指定的 block 找到两个不同的档名，而不管使用哪个档名均可以指到 real 那个 inode 去读取到最终数据！那这样有什么好处呢？最大的好处就是『安全』！如同上图中， 如果你将任何一个『档名』删除，其实 inode 与 block 都还是存在的！ 此时你可以透过另一个『档名』来读取到正确的文件数据喔！此外，不论你使用哪个『档名』来编辑， 最终的结果都会写入到相同的 inode 与 block 中，因此均能进行数据的修改哩！
一般来说，使用 hard link 配置链接文件时，磁盘的空间与 inode 的数目都不会改变！ 我们还是由图 2.2.1 来看，由图中可以知道， hard link 只是在某个目录下的 block 多写入一个关连数据而已，既不会添加 inode 也不会耗用 block 数量哩！
由图 2.2.1 其实我们也能够知道，事实上 hard link 应该仅能在单一文件系统中进行的，应该是不能够跨文件系统才对！ 因为图 2.2.1 就是在同一个 filesystem 上嘛！所以 hard link 是有限制的：
不能跨 Filesystem； 不能 link 目录。
2.Symbolic Link (符号链接，亦即是快捷方式)
相对于 hard link ， Symbolic link 可就好理解多了，基本上， Symbolic link 就是在创建一个独立的文件，而这个文件会让数据的读取指向他 link 的那个文件的档名！由于只是利用文件来做为指向的动作， 所以，当来源档被删除之后，symbolic link 的文件会『开不了』， 会一直说『无法开启某文件！』。实际上就是找不到原始『档名』而已啦！
举例来说，我们先创建一个符号链接文件链接到 /etc/crontab 去看看：
由上表的结果我们可以知道两个文件指向不同的 inode 号码，当然就是两个独立的文件存在！ 而且连结档的重要内容就是他会写上目标文件的『文件名』， 你可以发现为什么上表中连结档的大小为 12 bytes 呢？ 因为箭头(-->)右边的档名『/etc/crontab』总共有 12 个英文，每个英文占用 1 个 byes ，所以文件大小就是 12bytes了！
关于上述的说明，我们以如下图示来解释：
由 1 号 inode 读取到连结档的内容仅有档名，根据档名链接到正确的目录去取得目标文件的 inode ， 最终就能够读取到正确的数据了。你可以发现的是，如果目标文件(/etc/crontab)被删除了，那么整个环节就会无法继续进行下去， 所以就会发生无法透过连结档读取的问题了！
这里还是得特别留意，这个 Symbolic Link 与 Windows 的快捷方式可以给他划上等号，由 Symbolic link 所创建的文件为一个独立的新的文件，所以会占用掉 inode 与 block 喔！
ln
1.要注意啰！使用 ln 如果不加任何参数的话，那么就是 Hard Link 啰！如同范例二的情况，添加了 hard link 之后，可以发现使用 ls -l 时，显示的 link 那一栏属性添加了！而如果这个时候砍掉 passwd 会发生什么事情呢？passwd-hd 的内容还是会跟原来 passwd 相同，但是 passwd-so 就会找不到该文件啦
2.而如果 ln 使用 -s 的参数时，就做成差不多是 Windows 底下的『快捷方式』的意思。当你修改 Linux 下的 symbolic link 文件时，则更动的其实是『原始档』， 所以不论你的这个原始档被连结到哪里去，只要你修改了连结档，原始档就跟着变啰！ 以上面为例，由于你使用 -s 的参数创建一个名为 passwd-so 的文件，则你修改 passwd-so 时，其内容与 passwd 完全相同，并且，当你按下储存之后，被改变的将是 passwd 这个文件！
2.3 关于目录的 link 数量：
或许您已经发现了，那就是，当我们以 hard link 进行『文件的连结』时，可以发现，在 ls -l 所显示的第二字段会添加一才对，那么请教，如果创建目录时，他默认的 link 数量会是多少？ 让我们来想一想，一个『空目录』里面至少会存在些什么？呵呵！就是存在 . 与 .. 这两个目录啊！ 那么，当我们创建一个新目录名称为 /tmp/testing 时，基本上会有三个东西，那就是：
/tmp/testing
/tmp/testing/.
/tmp/testing/..
所以说，当我们创建一个新的目录时， 『新的目录的 link 数为 2 ，而上一级目录的 link 数则会添加 1 』 不信的话，我们来作个测试看看：
瞧！原本的所谓上一级目录 /tmp 的 link 数量由 5 添加为 6 ，至于新目录 /tmp/testing 则为 2 ，这样可以理解目录的 link 数量的意义了吗？ ^_^
3. 磁盘的分割、格式化、检验与挂载
3.1 磁盘分区： fdisk, partprobe
3.2 磁盘格式化： mkfs, mke2fs
3.3 磁盘检验： fsck, badblocks
3.4 磁盘挂载与卸除： mount, umount
3.5 磁盘参数修订： mknod, e2label, tune2fs, hdparm
4. 配置启动挂载：
4.1 启动挂载 /etc/fstab 及 /etc/mtab
4.2 特殊装置 loop 挂载(映象档不刻录就挂载使用)
5. 内存置换空间(swap)之建置：
还记得在安装 Linux 之前大家常常会告诉你的话吧！
就是安装时一定需要的两个 partition 啰！ 一个是根目录，另外一个就是 swap(内存置换空间)。关于内存置换空间的解释在第四章安装 Linux 内的磁盘分区 swap 的功能就是在应付物理内存不足的情况下所造成的内存延伸记录的功能
一般来说，如果硬件的配备足够的话，那么 swap 应该不会被我们的系统所使用到， swap 会被利用到的时刻通常就是物理内存不足的情况了。从
第零章的计算器概论 当中，我们知道 CPU 所读取的数据都来自于内存， 那当内存不足的时候，为了让后续的程序可以顺利的运行，因此在内存中暂不使用的程序与数据就会被挪到 swap 中了。 此时内存就会空出来给需要运行的程序加载。由于
swap 是用硬盘来暂时放置内存中的信息， 所以用到 swap 时，你的主机硬盘灯就会开始闪个不停啊！
虽然目前(2009)主机的内存都很大，至少都有 1GB 以上啰！因此在个人使用上你不要配置 swap 应该也没有什么太大的问题。 不过服务器可就不这么想了～由于你不会知道何时会有大量来自网络的要求，因此你最好能够预留一些 swap 来缓冲一下系统的内存用量！ 至少达到『备而不用』的地步啊！
现在想象一个情况，你已经将系统创建起来了，此时却才发现你没有建置 swap ～那该如何是好呢？ 透过本章上面谈到的方法，你可以使用如下的方式来创建你的 swap 啰！
配置一个 swap partition
创建一个虚拟内存的文件
5.1 使用实体分割槽建置swap
5.2 使用文件建置swap
5.3 swap使用上的限制
6. 文件系统的特殊观察与操作
6.1 boot sector 与 superblock 的关系
6.2 磁盘空间之浪费问题
我们在前面的
block 介绍中谈到了一个 block 只能放置一个文件， 因此太多小文件将会浪费非常多的磁盘容量。但你有没有注意到，整个文件系统中包括 superblock, inode table 与其他中介数据等其实都会浪费磁盘容量喔！所以当我们在 /dev/hdc6 创建起 ext3 文件系统时， 一挂载就立刻有很多容量被用掉了！
另外，不知道你有没有发现到，当你使用 ls -l 去查询某个目录下的数据时，第一行都会出现一个『total』的字样！ 那是啥东西？其实那就是该目录下的所有数据所耗用的实际 block 数量 * block 大小的值。 我们可以透过 ll -s 来观察看看上述的意义：
从上面的特殊字体部分，那就是每个文件所使用掉 block 的容量！举例来说，那个 crontab 虽然仅有 255bytes ， 不过他却占用了两个 block (每个 block 为 4K)，将所有的 block 加总就得到 104Kbytes 那个数值了。 如果计算每个文件实际容量的加总结果，其实只有 56.5K 而已～所以啰，这样就耗费掉好多容量了！
如果想要查询某个目录所耗用的所有容量时，那就使用 du 吧！不过 du 如果加上 -s 这个选项时， 还可以依据不同的规范去找出文件系统所消耗的容量喔！举例来说，我们就来看看 /etc/ 这个目录的容量状态吧！
使用 bytes 去分析时，发现到实际的数据占用约 103.3Mbytes，但是使用 block 去测试，就发现其实耗用了 118Mbytes， 此时文件系统就耗费了约 15Mbytes 啰！这样看的懂我们在讲的数据了吧？
6.3 利用 GNU 的 parted 进行分割行为
7. 重点回顾
以上是关于Linux日志式文件系统面面观的主要内容，如果未能解决你的问题，请参考以下文章
第八章Linux 磁盘与文件系统管理
理解Linux标准的文件系统(Ext2/Ext3/Ext4)
日志式文件系统
Linux文件系统详解
linux文件系统详解
Linux命令——磁盘操作及文件系统的管理