给大家在linux上文件系统选择上的一些建议 ZT

Linux环境下日志式文件系统

文件系统是用来管理和组织保存在磁盘驱动器上的数据的系统软件，其实现了数据完整性的保证，也就是保证写入磁盘的数据和随后读出的内容的一致性。除了保存以文件方式存储的数据以外，一个文件系统同样存储和管理关于文件和文件系统自身的一些重要信息(例如：日期时间、属主、访问权限、文件大小和存储位置等等)。这些信息通常被称为元数据(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日志式文件系统，可以从www.namesys.com下载，目前Mandrake8.1采用该日志式文件系统。SGI在2001年三月发布了XFS日志式文件系统。可以在 oss.sgi.com/projects/xfs/下载。下面将对这三种日志文件系统采用不同的工具进行检测和性能测试。

安装ext3

关于ext3文件系统技术方面的问题请参考Dr. Stephen Tweedie的论文和访谈。ext3日志式文件系统直接来自于其祖先ext2文件系统。其具有完全向后兼容的关键特性，实际上其仅仅是在ext2日志式文件系统上添加了日志功能。其最大的缺点是没有现代文件系统所具有的能提高文件数据处理速度和解压的高性能。

ext3从 2.2.19开始是作为一个补丁方式存在的。如果希望对内核添加对ext3文件系统的支持，就需要使用补丁，可以从ftp.linux.org.uk/pub/linux/sct/fs/jfs或ftp.kernel.org/pub/linux/kernel/people/sct/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。可以http://linux-xfs.sgi.com/projects/xfs/102_release.html从下载得到对内核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++性能测试程序(www.coker.com.au/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要稍微慢上一些(因为记录日志需要一些额外的时间)。 最后使用从www.namesys.com得到的性能测试程序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是最好的选择。

marlborolj 回复于：2003-05-27 15:36:11

在用ext3文件系统有时候会遇到这样的问题 机器突然断电，系统无法启动 提示错误 kernel  panic 这时候可能是你的某个启动文件损坏，而导致系统无法启动。用单用户模式也无法进入系统 好像在reiserFS文件系统没遇见过这样的问题！！

fancheng 回复于：2003-05-27 16:45:17

我使用REDHAT ADS2.1 操作系统，选用reiserFS 文件系统，但是好像次文件系统不支持2G以上的文件，听说只有SaSUjhjsg, 支持，不知道通过什么方式能支持次文件系统，谢谢！ 如方便发邮件给我 fancheng!

marlborolj 回复于：2003-05-27 17:10:26

2.4内核版本以上都应该支持ext3和reiserFS文件系统 能给我解释一下什么是“次文件系统” 这个名词比较陌生 这些文件系统至少能支持1T的文件 不过不是对rh ADS2.1 我是用其他的linux发行版本

弱智 回复于：2003-05-27 23:31:06

purge也想知道。 push~~~

marlborolj 回复于：2003-05-28 09:12:55

顶一下 “次文件系统”？

bombax 回复于：2003-05-28 17:14:13

明显是误敲啦，应该是：“此”。 [quote:30e302883c="marlborolj"]顶一下 “次文件系统”？[/quote:30e302883c]

弱智 回复于：2003-05-29 00:44:50

http://www.linuxworld.com/linuxworld/lw-2000-10/lw-10-penguin_4.html

marlborolj 回复于：2003-05-29 09:22:01

可以借这篇文章谈论一下linux文件系统 例如 jfs reiserFS ext3

marlborolj 回复于：2003-05-29 09:26:50

zt   IBMlinux技术中心 日志文件系统 (JFS) 提供了基于日志的字节级文件系统，该文件系统是为面向事务的高性能系统而开发的。它具有可伸缩性和健壮性，与非日志文件系统相比，它的优点是其快速重启能力：JFS 能够在几秒或几分钟内就把文件系统恢复到一致状态。 虽然 JFS 主要是为满足服务器（从单处理器系统到高级多处理器和群集系统）的高吞吐量和可靠性需求而设计的，JFS 还可用于想得到高性能和可靠性的客户机配置。 体系结构和设计 JFS 体系结构可从磁盘布局特性的角度进行说明。 逻辑卷 所有文件系统讨论的基础是某种类型的逻辑卷。这可以是一个物理磁盘，或物理磁盘空间的某个子集，例如：一个 FDISK 分区。逻辑卷也称为磁盘分区。 聚集和文件集 文件系统创建实用程序 mkfs，创建了完全包含在分区内的聚集。聚集是包含一种特定格式的磁盘块阵列，其格式包括超级块和分配映射表。超级块将分区标识成 JFS 聚集，而分配映射表描述聚集内每个数据块的分配状态。格式还包括描述它所必需的初始文件集和控制结构。文件集是可安装的实体。 文件、目录、inode 与寻址结构 文件集包含文件和目录。文件和目录由 inode 持续表示；每个 inode 描述文件或目录的属性，并作为查找磁盘上文件或目录数据的起始点。JFS 还使用 inode 来表示其它文件系统对象，如描述文件集中每个 inode 的分配状态和磁盘位置的映射表。 目录将用户特定的名称映射到为文件和目录所分配的 inode 上，并且形成传统的命名层次。文件包含用户数据，用户数据中没有隐含任何限制或格式。也就是说，JFS 将用户数据看成是未解释的字节流。根植于 inode 基于盘区的寻址结构用来将文件数据映射到磁盘。聚集超级块和磁盘分配映射表、文件描述符和 inode 映射表、inode、目录以及寻址结构一起表示了 JFS 控制结构或元数据。 日志 在每个聚集中维护 JFS 日志，并且用来记录元数据的操作信息。日志有一种同样由文件系统创建实用程序设置的格式。聚集内多个安装的文件集可以同时使用一个日志。 设计特性 JFS 从一开始就设计成完全集成了日志记录，而不是在现有文件系统上添加日志记录。JFS 的许多特性使之区别于其它文件系统。 日志处理 JFS 提供了改进的结构化一致性和可恢复性，以及比非日志文件系统（例如：HPFS、ext2 和传统 UNIX 文件系统）快得多的系统重启时间。发生系统故障时非日志文件系统容易崩溃，是由于一个逻辑写文件操作通常占用多个媒体 I/O 来完成，且在任何给定时间，可能没有完全反映在媒体上。这些文件系统依靠重启实用程序（也就是 fsck），fsck 检查文件系统的所有元数据（例如：目录和磁盘寻址结构）以检测和修复结构完整性问题。这是一个耗时并且容易出错的过程，在最糟糕的情况下，它还可能丢失或放错数据。 相反，JFS 使用原来为数据库开发的技术，记录了文件系统元数据上执行的操作（即原子事务）信息。如果发生系统故障，可通过重放日志并对适当的事务应用日志记录，来使文件系统恢复到一致状态。由于重放实用程序只需检查文件系统最近活动所产生的运行记录，而不是检查所有文件系统的元数据，因此，与这种基于日志的方法相关的文件系统恢复时间要快得多。 基于日志恢复的其它几个方面也值得注意。首先，JFS 只记录元数据上的操作，因此，重放这些日志只能恢复文件系统中结构关系和资源分配状态的一致性。它没有记录文件数据，也没有将这些数据恢复到一致状态。因此，恢复后某些文件数据可能丢失或失效，对数据一致性有关键性需求的用户应该使用同步 I/O。 面对媒体出错，日志记录不是特别有效。特别地，在将日志或元数据写入磁盘的期间发生的 I/O 错误，意味着在系统崩溃后，要将文件系统恢复到一致状态，需要耗时并且有可能强加的全面完整性检查。这暗示着，坏块重定位是任何驻留在 JFS 下的存储管理器或设备的一个关键特性。 JFS 日志记录的语义如下：当涉及元数据更改的文件系统操作--例如，unlink()--返回成功执行的返回码时，操作的结果已经提交到文件系统，即使系统崩溃了也可以发现。例如，一旦成功删除了文件，即使系统崩溃然后重启，它仍然是删除的并且不会再重新出现。 日志记录风格将同步写入日志磁盘引入每个修改元数据的 inode 或 vfs 操作。（对数据库专家而言，这是一种使用非剥夺缓冲区策略的仅重做的、物理残留映象、提前写的日志记录协议。）在性能方面，与依赖（多个）谨慎的同步元数据写操作以获得一致性的许多非日志文件系统相比，这种方法较好。但是，与其它日志文件系统相比，它在性能上处于劣势。其它日志文件系统，如 Veritas VxFS 和 Transarc Episode，使用不同的日志风格并且缓慢地将日志数据写入磁盘。在执行多个并行操作的服务器环境中，通过将多个同步写操作组合成单一写操作的组提交来减少这种性能损失。JFS 日志记录风格随着时间推移而得到不断改进，现在提供了异步日志记录，异步日志记录提高了文件系统的性能。 基于盘区的寻址结构 JFS 使用基于盘区的寻址结构，连同主动的块分配策略，产生紧凑、高效、可伸缩的结构，以将文件中的逻辑偏移量映射成磁盘上的物理地址。盘区是象一个单元那样分配给文件的相连块序列，可用一个由 <逻辑偏移量，长度，物理地址> 组成的三元组来描述。寻址结构是一棵 B+ 树，该树由盘区描述符（上面提到的三元组）填充，根在 inode 中，键为文件中的逻辑偏移量。 可变的块尺寸 按文件系统分，JFS 支持 512、1024、2048 和 4096 字节的块尺寸，以允许用户根据应用环境优化空间利用率。较小的块尺寸减少了文件和目录中内部存储碎片的数量，空间利用率更高。但是，小块可能会增加路径长度，与使用大的块尺寸相比，小块的块分配活动可能更频繁发生。因为服务器系统通常主要考虑的是性能，而不是空间利用率，所以缺省块尺寸为 4096 字节。 动态磁盘 inode 分配 JFS 按需为磁盘 inode 动态地分配空间，同时释放不再需要的空间。这一支持避开了在文件系统创建期间，为磁盘 inode 保留固定数量空间的传统方法，因此用户不再需要估计文件系统包含的文件和目录最大数目。另外，这一支持使磁盘 inode 与固定磁盘位置分离。 目录组织 JFS 提供两种不同的目录组织。第一种组织用于小目录，并且在目录的 inode 内存储目录内容。这就不再需要不同的目录块 I/O，同时也不再需要分配不同的存储器。最多可有 8 个项可直接存储在 inode 中，这些项不包括自己(.)和父(..)目录项，这两个项存储在 inode 中不同的区域内。 第二种组织用于较大的目录，用按名字键控的 B+ 树表示每个目录。与传统无序的目录组织比较，它提供更快的目录查找、插入和删除能力。 稀疏和密集文件 按文件系统分，JFS 既支持稀疏文件也支持密集文件。 稀疏文件允许把数据写到一个文件的任意位置，而不要将以前未写的中间文件块实例化。所报告的文件大小是已经写入的最高块位处，但是，在文件中任何给定块的实际分配，只有在该块进行写操作时才发生。例如，假设在一个指定为稀疏文件的文件系统中创建一个新文件。应用程序将数据块写到文件中第 100 块。尽管磁盘空间只分配了 1 块给它，JFS 将报告该文件的大小为 100 块。如果应用程序下一步读取文件的第 50 块，JFS 将返回填充了 0 的一个字节块。假设应用程序然后将一块数据写到该文件的第 50 块，JFS 仍然报告文件的大小为 100 块，而现在已经为它分配了两块磁盘空间。稀疏文件适合需要大的逻辑空间但只使用这个空间的一个（少量）子集的应用程序。 对于密集文件，将分配相当于文件大小的磁盘资源。在上例中，第一个写操作（将一块数据写到文件的第 100 块）将导致把 100 个块的磁盘空间分配给该文件。在任何已经隐式写入的块上进行读操作，JFS 将返回填充了 0 的字节块，正如稀疏文件的情况一样。 JFS 内部（潜在）限制 JFS 是完全 64 位的文件系统。所有 JFS 文件系统结构化字段都是 64 位大小。这允许 JFS 同时支持大文件和大分区。 文件系统大小 JFS 支持的最小文件系统是 16M 字节。最大文件系统的大小是文件系统块尺寸和文件系统元数据结构支持的最大块数两者的乘积。JFS 将支持最大文件长度是 512 万亿字节（TB）（块尺寸是 512 字节）到 4 千万亿字节（PB）（块尺寸是 4K 字节） 文件长度 最大文件长度是主机支持的虚拟文件系统最大文件长度。例如：如果主机只支持 32 位，则这就限制了文件长度。 可移动媒体 JFS 不支持把软盘作为基本文件系统设备。 标准管理实用程序 JFS 提供创建和维护文件系统的标准管理实用程序。 创建文件系统 这个实用程序提供 mkfs 命令的 JFS 特定部分，用来在指定的驱动器上初始化 JFS 文件系统。该实用程序在较低级别上操作，并假设文件系统所存在的任何卷的创建/初始化由更高级别的另一个实用程序处理。 检查/修复文件系统 这个实用程序提供 fsck 命令的 JFS 特定部分。该命令检查文件系统的一致性，修复发现的问题。它也重放日志，把提交的改动应用到文件系统元数据，如果由于日志重放而声明文件系统是干净的，就不会再采取进一步操作。如果文件系统不认为是干净的，这意味着由于某种原因没有完整和正确地重放日志，或者文件系统不能单靠重放日志来恢复到一致状态，那么，就对文件系统执行一遍完整检查。 当执行全部完整性检查时，检查/修复实用程序首要目的是要达到可靠的文件系统状态，以防止将来文件系统崩溃或故障，第二个目的就是面对崩溃时保存数据。这意味着为了达到文件系统的一致性，实用程序可能丢弃数据。具体而言，当实用程序在不做假设的情况下，无法获得所需信息以将结构上不一致的文件或目录恢复到一致状态时，就会废弃数据。当遇到不一致的文件或目录时，就废弃整个文件或目录，而不再试图保存任何部分。任何由删除受损目录所孤立起来的文件或子目录，都放在文件系统根下的 lost+found 目录中。 文件系统检查/修复实用程序重点考虑的因素之一是所需虚存数量。通常，这些实用程序所需的虚存数量由文件系统的大小决定，这是由于所需虚存主要用于跟踪文件系统中个别块的分配状态。随着文件系统增大，块的数量增多，用来跟踪这些块所需的虚存数量也随之增加。 JFS 检查/修复实用程序的设计区别在于其虚存需求由文件系统中文件和目录的数量（而不是由块的数量）所决定。对 JFS 检查/修复实用程序而言，每个文件或目录的虚存大约为每个文件或目录 32 字节，或者对于包含百万个文件和目录的文件系统而言，不论其文件系统大小，虚存需求都是大约 32 兆字节。如同所有其它的文件系统，JFS 实用程序需要跟踪块分配状态，但避免使用虚存方法，而是使用位于实际文件系统中的一小块保留工作区来实现。 结束语 因为在系统崩溃时，JFS 能提供快速文件系统重启时间，所以它是因特网文件服务器的关键技术。使用数据库日志处理技术，JFS 能在几秒或几分钟之内把文件系统恢复到一致状态。而在非日志文件系统中，文件恢复可能花费几小时或几天。大部分文件服务器用户不能容忍与非日志文件系统相关的停机时间。只有通过转移到日志技术，这些文件系统才能避免需要检查文件系统的所有元数据才能验证文件系统或将其恢复到一致状态这一耗时的过程。

marlborolj 回复于：2003-05-29 09:27:50

什么是ReiserFS 　　它通过一种与众不同的方式--完全平衡树结构来容纳数据，包括文件数据，文件名以及日志支持。ReiserFS还以支持海量磁盘和磁盘阵列，并能在上面继续保很快的搜索速度和很高的效率。ReiserFS文件系统一直以来被用在高端Unix系统上如SGI等。  2． ReiserFS的特点（与ext2的对比）:  ReiserFS相对于Linux上传统的文件系统--ext2有很多优点，在下面一一介绍。  ·搜寻方式  　　ReiserFS是基于平衡树的文件系统结构，尤其对于大量文件的巨型文件系统，如服务器上的文件系统，搜索速度要比ext2快；ext2使用局部的二分查找法，综合性能比不上ReiserFS。  ·空间分配和利用情况  　　ReiserFS里的目录是完全动态分配的，因此不存在ext2中常见的无法回收巨型目录占用的磁盘空间的情况。ReiserFS里小文件（<4K）可以直接存储进树，小文件读取和写入的速度更快，树内节点是按字节对齐的，小的文件可共享同一个硬盘块，节约大量空间。Ext2使用固定大小的块分配策略，也就是说，不到4K的小文件也要占据4K的空间，导致的空间浪费比较严重。  ·先进的日志机制  　　ReiserFS有先进的日志(Journaling/logging)机制，在系统意外崩溃的时候，未完成的文件操作不会影响到整个文件系统结构的完整性。 ext2虽然健壮性很强，但一旦文件系统被不正常地断开，在下一次启动时它将不得不进行漫长的检查系统数据结构的完整性的过程，这是为了防止数据丢失而必需的操作。对于较大型的服务器文件系统，这种"文件系统检查"可能要持续好几个小时，在很多场合下这样长的时间是无法接受的。 解决这个问题的一种技术"日志文件系统"。在日志的帮助下，每个对数据结构的改变都被记录下来，日志在机制保证了在每个实际数据修改之前，相应的日志已经写入硬盘。正因为如此，在系统突然崩溃时，在下次启动几秒钟后就能恢复成一个完整的系统，系统也就能很快的使用了。  ·支持海量磁盘和优秀的综合性能  　　ReiserFS是一个相当现代化的文件系统，相比之下，ext2虽然性能已经很好了，但其设计还只是19世纪80年代的水准。ReiserFS的出现，使Linux拥有了像Irix/AIX那样的高档商用Unix才有的高级文件系统。ReiserFS可轻松管理上百G的文件系统，在企业级应用中有其用武之地，由于它的高效存储和快速小文件I/O特点，它在桌面系统上也表现出色：启动X窗口系统的时间ReiserFS比ext2少1/3。而ext2则无法管理2G以上的单个文件，这也使得ReiserFS在某些大型企业级应用中比ext2要出色。  3．缺点  　　ReiserFS一个最受人批评的缺点是每升级一个版本，都将要将磁盘重新格式化一次，这个缺点也正在改进中。

marlborolj 回复于：2003-05-29 09:29:09

用于Linux的日志文件系统 最近12个月以来，Linux已经巩固了其作为服务器操作系统的地位。就像集群（cluster）对于企业级的应用很重要那样，日志文件系统（journaling file system）也是同样重要的。 为什么日志文件系统很重要呢？它是怎样工作的呢？有哪些日志文件系统可以用于Linux？ 日志文件系统比传统的文件系统安全，因为它用独立的日志文件跟踪磁盘内容的变化。就像关系型数据库（RDBMS），日志文件系统可以用事务处理的方式，提交或撤消文件系统的变化。 Ext2不能满足要求 尽管Linux可以支持种类繁多的文件系统，但是几乎所有的Linux发行版都用ext2作为默认的文件系统。Linux可以支持的文件系统有：FAT、VFAT、HPFS（OS/2）、NTFS（Windows NT）、Sun的UFS，等等。 ext2的设计者主要考虑的是文件系统的效率和性能方面的问题。ext2在写入文件内容的同时并没有同时写入文件的meta-data（和文件有关的信息，例如：权限、所有者以及创建和访问时间）。换句话说，Linux先写入文件的内容，然后等到有空的时候才写入文件的meta-data。如果在写入文件内容之后但在写入文件的meta-data之前，突然断电了，文件系统就会处于不一致的状态。在一个需要大量文件操作的系统中（例如，像Hotmail这样的免费的Web e-mail），出现这种情况会导致很严重的后果。日志文件系统可以帮助解决这个问题。 假定你正在更新一个目录项（directory entry）。你已经在这个巨大的目录项的第五个文件块（block）中改变了23个文件项（file entry）。当正在写这个文件块的时候突然间断电了，这个文件块还没有写完，也就是被损坏了。 重新启动的时候，Linux（就像其它的Unix）会运行一个叫做“fsck”（file system check）的程序，扫描整个文件系统，保证所有的文件块都被正确地分配或使用。它将找到这个被损坏的目录项并试图修复它，但是不能够保证fsck一定能够修复损坏。修复不了是经常的事。所以，当出现上面那种情况，目录项中所有的文件项可能会丢失，也就造成文件的丢失。 如果文件系统很大，fsck扫描要费很长时间。在一个有数十亿个文件的计算机上，fsck可能要运行10个小时以上。在这段时间内，系统是不可用的，也就是导致了很长的当机时间。日志文件系统可以避免这种情况。 文件系统是怎样工作的？ 文件系统通过为每个文件分配文件块的方式把数据存储在存储设备中。这样就要维护每一个文件的文件块的分配信息，而分配信息本身也要存在磁盘上。DOS和Windows的用户可能还记得FAT这种文件系统吧。不同的文件系统用不同的方法分配和读取文件块。 有两种常用的文件系统的分配策略：块分配（block allocation）和扩展分配（extent allocation）。块分配当文件变大的时候每一次都为这个文件分配磁盘空间，而扩展分配则是当某个文件的磁盘空间不够的时候，一次性为它分配一连串连续的块。 传统的Unix文件系统使用的块分配的机制提供了一个灵活而高效的文件块分配策略。磁盘上的文件块根据需要分配给文件，这样可以减少存储空间的浪费。当一个文件慢慢变大的时候，就会造成文件中文件块的不连续。这就导致了过多的磁盘寻道时间，当读取一个文件的时候有可能要随机而不是连续地读取文件块，这样的效率很低。 可以通过优化文件块的分配策略（尽可能为文件分配连续的块）来避免文件块的随机分配。通过使用聪明的块分配策略，可以实现块的连续分配。这样就可以减少磁盘的寻道时间。但是，当整个文件系统的文件块的分配形成碎片的时候，就再也不可能连续分配了。 每一次当文件扩展的时候，块分配的算法就要写入一些关于新分配的块所在位置的信息。如果每一次文件扩展的时候只增加一个块，那么就需要很多额外的磁盘I/O用来写入文件块的结构信息。文件块的结构信息也就是上面说的meta-data。meta-data总是一起同时地写入存储设备的，这就意味着改变文件大小的操作要等到所有的meta-data的操作都完成之后才能进行。因此，meta-data的操作会显著地降低整个文件系统的性能。 基于扩展（Extent-based）的分配方式 扩展分配方式一次性为文件分配很多连续的块。当创建一个文件的时候，很多文件块同时被分配；当文件扩展的时候，也一次分配很多块。文件系统的meta-data在文件创建的时候被写入，当文件的大小没有超过所有已分配的文件块的大小，就不用写入meta-data。（直到需要再分配文件块的时候） 这样可以优化磁盘寻道的方式，可以成组地分配块，有利于一次写一大批数据到存储设备中，这样就可以减少SCSI设备写数据的时间。     基于扩展分配的文件系统在读取顺序文件的时候有很好的性能，因为文件块都是成组连续分配的。但是，如果I/O操作是随机的，基于扩展分配的文件系统的好处就非常有限了。例如，当我们要连续地读取一个基于扩展分配的文件的时候，我们只要读起始块号和文件长度就行了。然后，就可以连续地读取所有的文件块了，这样在顺序读取文件的时候，读meta-data的开销就很小。反之，如果随机地读取文件，我们就要先查找每一个所需块的块地址然后再读取块的内容，这样就和块分配方式很象了。 在ext2文件系统中，对写性能的增强是通过尽量延迟写的时间，这样就能一次写一大批数据而不是每次写一小点。随之而来的就是系统效率的提高。同样，当读的时候，ext2也是一次读取一整组的块，也就是采用预读策略。这样就能提高ext2文件系统的读性能，大量减少每次读取少量数据的I/O操作。 文件块的组或块簇（block cluster）的大小是在编译的时候确定的。怎样设定簇的大小不是这篇文章所要介绍的内容。但是，可以这么说，簇的大小对文件系统的性能确实有很大的影响，而且簇的大小也是文件系统设计的时候需要考虑的一个很重要的方面。 象Veritas这样的扩展分配的文件系统和象ext2这样的“成簇写”（write-clustering）的文件系统，在默认情况下都使用512字节的块而不用1k字节的块。如果ext2用4k而不是1k字节的块，大概会有20%的性能提升。但是，为了减少被浪费的空间ext2文件系统的设计者建议使用1k字节的块。 日志文件系统是怎样解决问题的？ 先提醒你一下：这节标题可能容易导致误解。日志文件系统确实解决了上面提到的一些问题，但是又带来了新问题。 日志文件的设计思想是跟踪文件系统的变化而不是文件系统的内容。为了更好地解释这个问题，下面我用ext2文件系统和日志文件系统举一个例子： 当我们改变文件“test.file”的内容的时候会出现什么情况？先假定“test.file”的inode有四个数据块。用来保存“test.file”文件的数据块的块号分别为3110、3111、3506和3507（因为在3111和3506之间的块已经分配给其它文件了，所以这些块不连续）。当硬盘要先找到3100，读两块，在跳到3500，再读两块，才能读取整个文件。假定你改变了第三块，文件系统会读取第三块，改变它，然后重新写入第三块，这一块还在3506这个位置。如果你往文件中添加了一些内容，就要从别的地方另外分配一些空余的块。 如果在日志文件系统中，情况就有所不同。日志文件系统不会改变第3506块的内容，它会把“test.file”的inode的一个拷贝和新的第三块保存到磁盘上。在内存中的inode列表需要更新，让“test.file”使用新的inode。所有的变化、添加和改变需要被记录到一个文件系统中被称为“日志”的那部分中去。每隔一段时间，文件系统在“检查点”（check point）回更新在磁盘上的inode，并且释放文件中用不到的那些旧块（例如：“test.file”文件最初的第三块）。 在系统崩溃之后，日志文件系统很快就能恢复。它需要恢复的只是日志中记录下来的很少的几块。当断电之后，“fsck”只要用几秒钟的扫描时间。 这就是我所说的解决了一些问题！ 但是，文件系统为得到额外的安全也是要付出代价的，这就是系统开销。每一次更新和大多数的“日志”操作都需要写同步，这样就需要更多的磁盘I/O操作。系统管理员就面临这样一个问题：为了有一个更安全的文件系统值不值得牺牲一部分性能？ 大多数系统管理员会根据实际情况作出决定。没有必要把“/usr”目录放在日志文件系统上因为“/usr”目录大部分是只读的操作。但是，可以考虑把“/var”或包含e-mail spool文件的目录放在日志文件系统上。幸运的是在Linux系统中可以根据需要混合使用这些文件系统。 日志文件系统还有一个问题就是更容易产生碎片。因为它的文件分配方式与众不同，很容易在文件系统中到处产生碎片。ext2文件系统也会产生碎片但是可能不会有这么严重。每个月定期把文件系统备份到磁带中然后重新恢复，不仅可以解决这问题，而且可以检查备份/恢复的过程是否正确。 想得到一些好处，总是要付出一些代价的，不是吗？ 可供选择的Linux日志文件系统 当我写这篇文章的时候，有两个日志文件系统还在开发，有三个日志文件系统可供使用。 SGI的xfs（http://oss.sgi.com/projects/xfs/）日志文件系统和Veritas（www.veritas.com）的文件系统和卷管理（volume manager）。这两个文件系统在五个月前就发布了，但是现在还不能得到源代码。SGI的xfs是基于Irix（SGI的Unix）上已经实现的xfs。SGI已经宣布xfs为Open Source的软件。 两个马上就可以得到的日志文件系统是reiserfs和IBM的jfs。这两文件系统都是开放源代码的而且很多有天赋的人在开发这两个文件系统。jfs（Journaled File System Technology for Linux）的开发者包括AIX（IBM的Unix）的jfs的主要开发者。 在AIX上，jfs已经经受住了考验。它是可靠、快速和容易使用的。Reiserfs应用了一些新的技术，例如，统一名字空间（unified name space），是非常有前途的（Namesys）可以参考。 有一些Linux的发行版已经包括了reiserfs文件系统，作为安装时的可选项。SuSE 6.4 就很容易使用reiserfs文件系统。reiserfs的最新版是3.5.12，经过测试reiserfs的基准测试的结果是很激动人心的。这个测试使用“postmark”基准测试，50，000个事务处理20,000个文件。结果是： Sun E450 1 GB, Solaris 2.6, and vxfs (Veritas) file system: 22 transactions/second Sun E450 1 GB, Solaris 2.6, and UFS file system: 23 transactions/second Dual P-III, 1 GB Linux 2.2.13, standard ext2: 93 transactions/second Dual P-III, 1 GB Linux 2.2.13, reiserfs 3.5.5 journaling beta: 196 transactions/second Dual P-III, 1 GB Linux 2.2.13, reiserfs 3.5.5 journaling beta, mount options notail,  genericread: 847 transactions/second （Sun的计算机用的是barracuda硬盘，x86的计算机用的是cheeta硬盘） 还有一个日志文件系统是jfs。jfs还没有被任何Linux发行版采用，因为它现在的版本是0.7。但是，jfs进展得很快。本文的作者已经加入jfs项目现在是jfs FAQ的维护者。 reiserfs和jfs都非常容易安装。下载完jfs的软件包之后，还有下面几个步骤要完成： 1)1)        解压jfsXXX.tar.gz。 2)2)        软件带有内核（2.2.14、2.2.15和2.3.99）的补丁。把补丁拷贝到内核源代码的目录，通常在“/usr/src”。把补丁打到内核上，用这个命令： root@ maguro /usr/src #  patch -p0 3)3)        重新编译内核 root@ maguro /usr/src #  make menuconfig; make dep; make clean; make bzImage; make modules 安装reiserfs的步骤和上面类似： 1)1)        下载软件包。 2)2)        把补丁拷贝塔内核源代码所在的目录，通常在“/usr/src”，给内核打补丁： root@ maguro /usr/src #  zcat linux-2.2.11-reiserfs-3.5-patch.gz  | patch -p0 3)3)        编译内核。 4)4)        用下面命令生成reiserfs文件系统： root@ maguro /usr/src #  /linux/fs/reiserfs/utils/mkreiserfs /dev/hda2   另一个选择 日志文件系统的另一个选择是ext2的后继者ext3fs文件系统。ext3fs文件系统正在Linux内核黑客Stephen Tweedie的领导下开发。 ext3fs还处于beta测试阶段，就像reiserfs和jfs，但是它工作得很好。Stephen预计2000年夏天可以正式发布ext3fs。ext3fs最大的优点是向下兼容ext2。而且ext3fs还支持异步的日志，这意味着它的性能可能还比ext2好。 安装ext3fs和安装jfs和reiserfs类似。从这下载补丁：ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs。 就像reiserfs，ext3fs可能不久就会成为标准Linux内核的一部分，可能是2.4版的Linux内核。 最后几句话 现在还很难说jfs、ext3fs和reiserfs这三种日志文件系统到底哪一个会最后胜出。最后很有可能是多种日志文件系统并存。因为我加入jfs项目，所以我觉得jfs还是很有希望的。 现在，reiserfs用得最广泛，因为SuSE的6.3和6.4版已经包含它了。将来SGI的xfs源代码发布了，它也有可能成为有力的竞争者。如果你现在想要一个日志文件系统，那么你可以试试reiserfs。

alstone 回复于：2003-05-29 09:30:10

jfs 在linux上的实现不好。不够稳定。 AIX+LVM +jfs 是一个经典组合。 可以动态增大文件系统，对卷的理解极透彻。 但是linux ＋lvm＋reiserfs从可管理性上完全超越了他。 只是稳定性还略有欠缺。

happykai 回复于：2003-10-19 12:34:21

幸好我还没装，开始想用默认的ext2，结果装到一半盘出问题了，幸运啊

原文转自：http://www.ltesting.net