碰到kernel-2.4.18-4SGI_XFS_1.1内核后,对文件系统有了解.

weixiao

究竟文件系统是什么?

文件系统是某一存储设备上数据的结构和组织,打个比方:
你捐一本书到图书馆,跟管理员办好借书证.过了几天,亲自
到图书馆寻找回那本书,这个过程可看作文件系统的模型.
而尝试或使用别的文件系统,比作到其他图书馆借书,去领略
管理方式和装修.

SGI的XFS文件系统在(http://oss.sgi.com/projects/xfs/)
可得到.他们作了个测试报告,我译了几段:

####################################################
------------------------
........................................
XFS 不是标准Linux内核
------------------------
........................................
试验结果如下:
1 )基本文件I/O 在小系统上的集中的工作量,所有文件系统
有相同的表现。
2 )作为小文件I/O请求大小不到文件系统标准大小,并使用
操作系统集中的工作量,ReiserFS 可以是最快的.
3 )作为更大的文件I/O请求大小可看作跟文件系统相等大小,
并且使用的文件系统操作集中的工作量,有  data=ordered的
Ext2 或 Ext3 可以是最快的。
------------------------
------------------------
一个更大的系统适当的优化不等于在小系统环境是有益的.
------------------------
........................................
####################################################

报告总拿XFS同Ext2性能作数字上比较,图文并茂,但有个问题
,XFS是日志文件系统,而Ext3才是日志文件系统,什么意思?

ext2在写入文件内容的同时并没有同时写入文件的元数据(文
件权限、所有者以及创建和访问时间).Linux先写入文件的内
容，然后等到有空的时候才写入文件的元数据.这样若出现写
入文件内容之后但在写入文件的元数据之前系统突然断电,就
可能造成在文件系统就会处于不一致的状态.(摘)

日志文件系统比传统的文件系统安全,因为它用独立的日志文
件跟踪磁盘内容的变化.就像关系型数据库（RDBMS),日志文
件系统可以用事务处理的方式,提交或撤消文件系统的变化.
(摘)

在分区中保存有一个日志记录文件,文件系统写操作首先是对
记录文件进行操作,若整个写操作由于某种原因(如系统掉电)
而中断,则在下次系统启动时就会读日志记录文件的内容来恢
复没有完成的写操作.而这个过程一般只需要几秒钟到几分钟,
而不是ext2文件系统的fsck那样在大型服务器情况下可能需要
几个小时来完成扫描.(摘)

可升级性
　　xfs被设计成可升级,以面对大多数的存储容量和i/o存储
需求.可处理大型文件和包含巨大数量文件的大型目录.满足二
十一世纪快速增长的磁盘需求.xfs有能力动态地为文件分配索
引空间.使系统形成高效支持大数量文件的能力.在它的支持下.
用户可使用大文件,远远大于现在最大的文件系统.(摘)

优秀的i/o 性能
　　典型的现代服务器使用大型的条带式磁盘阵列.以提供达数
gb/秒的总带宽.xfs可以很好地满足i/o请求的大小和并发i/o请
求的数量.(摘)

系统排错
　　xfs可以在一秒内从大多数意外中断中恢复.传统文件系统必
须在中断后做一些特定的文件系统检查,可能会花费数小时才完成
.xfs避免了冗长的文件系统检查.可明显地减少读写磁盘的时间.
xfs可作为root文件系统,并被lilo支持.在NFS服务器上使用也没
问题.支持软件raid和LVM.(摘)

以我看来:XFS当前最好性能表现在I/O方面,在大系统上表现优于
其他日志系统.

weixiao

论坛搜索两标题:

"碰到kernel-2.4.18-4SGI_XFS_1.1内核,才发现"

"杂牌内核驱动内猫全实例"

6692975

原文在:
http://www-900.ibm.com/developer ... /l-fs11/index.shtml
XFS 有什么新鲜事吗？
在过去的几个月中，选择 XFS 作为 Linux 文件系统成为一件很流行的事。根据来自 Gentoo Linux 用户的反馈，人们之所以喜欢是因为它具有健壮的功能集，而且一般情况下，它的整体性能良好。不过，XFS 的 1.0.x 发行版有一个严重的问题。您也许还记得，如果更新的是文件的元数据，但是某种不可预知的情况（如崩溃）导致无法将新数据写到磁盘上，那么象 XFS 和 ReiserFS 这样的“只支持元数据”的日志文件系统就会引起数据破坏。对于 ReiserFS，受影响的文件会包含受损的或无用的数据块，而对于 XFS，该文件会包含整块的二进制零。事实证明，如果您的服务器碰巧崩溃或者意外断电，XFS 1.0.x 有一种很不好的倾向，那就是会破坏最近修改过的文件。那些刚好在承受力较强的服务器上使用 XFS 的人一般都没问题，但那些在遇到某种软件或硬件稳定性问题的系统上运行 XFS 的人就面临着丢失很多数据的风险。

幸运的是，SGI XFS 的开发人员在 XFS 1.1 中大大减少了这个问题的出现次数。这个问题之所以在 XFS 1.0 中更加频繁的发生，原因在于对某类元数据的更新必须按照其发生的顺序记录到文件系统中。这些按照顺序的元数据更新（被称为“同步”元数据更新）同样有将所有以前还没更新到磁盘上的元数据都刷新的效果。问题就出在这儿。如果这些早先的元数据刷新中也有一些相应的数据块需要被刷新，那么很可能在元数据被记录之后的半分钟内新的数据块仍然没有被写到磁盘上去。这就给发生数据丢失创造了一个很大的漏洞。
技术说明

对于 XFS 1.1，文件系统的元数据只在两种情况下会同步（有序）更新：

    * 如果文件系统需要分配空间，并且有一个紧随的事务来释放同一块空间
    * 在 XFS 处理用 O_SYNC（同步）选项打开的文件事务的时候；在这种情况下，对这个文件进行写操作将会使得文件系统对元数据所做的其它任何紧随其后的更改被刷新到磁盘。

幸运的是，绝大多数典型的服务器的 I/O 操作在本质上都是异步的。

如果在这个漏洞开启期间（在元数据被刷新之后但是在相应的数据被写到磁盘上之前）重新启动系统或系统死机，那么新老数据都会丢失。出现这种情况的原因如下：元数据更新删除了对原先数据块的任何引用，却指向磁盘上没有填充过数据的数据块。服务器在崩溃后再次启动时，XFS 代码会查看日志，了解情况，把那些不完整的数据块填上二进制零以预防安全性问题。不幸的是，数据就永远丢失了。

这个问题在频繁使用全新的数据覆盖文件的情况下尤其麻烦。在这样的情况下，如果系统恰好在不合适的时候死机了，那么前面刷新过的元数据会导致文件内容整个丢失。这种特殊的情况 gentoo.org 服务器也遇到过几次，丢失了数据。由于每隔几分钟我们的邮差邮件列表软件就会用新数据覆盖它自己的配置文件，因此它最有可能发生上面所描述的情况。

这个故事寓意是这样的：SGI 的开发者在 XFS 1.1 中已经大大改善了这种局面，如果您运行的是 XFS 1.0，那么您应该下定决心尽快升级到 XFS 1.1。XFS 1.1 还包括了许多附加的修订。在 SGI 缓解了 XFS 对同步元数据更新的依赖的时候，它还能改进 XFS 1.0.x 的弱点之一 — 文件删除。真是太棒了！

过不了多久，我们还可以期待看到 XFS 的新发行版，它将更适合于 Intel Itanium 平台。目前，XFS 的 Linux 版本要求 XFS 文件系统块的大小与平台的内存页面大小相同。这常常使得在 x86 系统上的磁盘不可能移到 Itanium 系统上，因为 Itanium 可以使用最大 64K 的页面，而 x86 只能用 4K。此外，对于大多数的任务来说，大小为 64K 的文件系统块并非最佳选择，但当前的代码迫使一些 Itanium 系统必须使用这样的文件系统块大小。如果修复了这个块大小问题，不仅将 XFS 文件系统从 x86 迁移到 ia64 上变得容易了，而且提供了一个额外的好处，就是允许系统管理员选择适合于他们的需要的 XFS 文件系统块大小。

ReiserFS
ReiserFS 文件系统堪称最有魄力的日志文件系统开发项目，因为它不只是将现有的文件系统移植到 Linux 内核（比如：XFS、JFS），它的设计也不是象 ext3 那样基于早先的文件系统。相反，ReiserFS 的设计完全是从头开始的，就其处理小文件而言，有一些非常吸引人的性能指标。那么，自从 ReiserFS 被引入到 2.4 内核以来，它是怎样解决稳定性问题和一般的文件系统健壮性问题的呢？

从引入 ReiserFS 开始，它一直有数目非常多的稳定性和崩溃问题。有很多内核对 ReiserFS 用户来说根本就是噩梦，其中包括 2.4.3、2.4.9 甚至相对较新的 2.4.16。不过，尽管这些问题中有些是因 ReiserFS 文件系统代码本身的错误引起的，但有数目惊人的问题会因对内核的其它部分所做的修改而产生不希望的副作用。Linux 内核的开发过程中有一件不幸的事就是，无论您多么细心的测试您自己的代码，还是可能会有某个另外的内核开发者插入的一条很可能没有经过测试的更改而导致您的代码崩溃。最常见的情况是，只有在这些不希望的副作用已经被引入并向深信不疑的 Linux 计算公众用户发行之后，开发者之间才会有交流。我认为，公平的说，有相当多的伤心的 ReiserFS 用户，他们发现自己正处于这一不幸的失败的环境中。

但是，我的朋友，好消息来了。在过去的几个月中，对于 ReiserFS 来说，情况看上去已经开始好转许多了。一是内核源代码开始稳定在 2.4.17 发行版。此外，在过去的几个月来 Namesys 的开发者（ReiserFS 的开发者）已经能修复相当多隐藏在他们的代码中的错误了。甚至还有更好的消息，内核 2.4.18 好象有一个非常稳定的 ReiserFS 实现。2.4.18 绝非新出现的 — 在写这篇文章的时候，它出现已经将近三个月了，在代码中还没有发现任何重大问题。事实上，由于缺少新来的错误报告，Namesys 已经重新给发行版经理（Release Manager）指派了新的工作，改进 ReiserFS 的性能。

因此，ReiserFS 和 2.4 内核好象最终解决了它们的差异问题。就我个人观点而言，这真是振奋人心的消息；我很想再开始使用 ReiserFS，并计划在我下一次重新加载我的开发工作站时用它作为我的根文件系统。因为内核方面的问题已经平静下来了，我确信，现在有许多别的前 ReiserFS 用户也很愿意再次回到 ReiserFS。坦白的说，一旦您看到 ReiserFS 的小文件性能可以给某些应用程序的性能带来多大的提升，就很难再离开它了。

那么，在不远的将来我们期望在 ReiserFS 看到些什么呢？据 Hans Reiser 和他的开发者小组所说，预计在 2.4.20_pre1 会有一些非常好的改进，包括对 Chris Mason 的数据日志（象 ext3 的“data=journal”模式）的支持、伸缩性要好得多的新的块分配代码以及对大文件性能方面的一些改进，预计从 IDE 驱动器读取大文件时性能的提高要高达 15%。除这些马上就要着手进行的重大改进之外，我们很可能会看到 ReiserFS 将支持与 ext3 的“data=ordered”模式等价的模式。在这个问题上，ReiserFS 将提供和在 ext3 文件系统中发现的一样的数据完整性功能。我很高兴的看到 ReiserFS 开发小组正在将数据完整性（而不只是元数据完整性）提到这样高的优先级。

Ext3
那么，ext3 的情况如何呢？通常，ext3 相当稳定，还没有遇到过重大问题。为此，ext3 堪称非常可靠而且健壮的日志文件系统选择。尽管有些人也许会认为这个文件系统很“沉闷”，因为除很好的日志实现之外，看不出它对 ext2 做了任何重大改进，但“沉闷”在文件系统世界中是一件好事。它意味着文件系统很擅长只是不紧不慢的执行它的工作。此外，虽然与 ResierFS、XFS 和 JFS 相比，ext3 的可伸缩性具有局限性，但 ext3 已经证明，在大多数服务器和工作站所执行的典型文件系统操作中使用，它不仅速度很快而且很容易调整。很明显，ext3 开发者已经达到了他们要创建一个高质量的日志文件系统的目标，Linux 用户不用费什么力气就可以放心的升级到这一文件系统。

对于内核 2.4.19_pre5，现在同步安装 ext3 文件系统和“chattr +S”文件比从前快大约十倍。很快，我们有望看到添加一个选项用于特定目录树的同步更新，这个功能将主要用于邮件程序。此外，我们还期望能看到定期对代码进行小错误修复和性能改进，但是不会修改主要部分；ext3 已经很完美了，现在代码似乎处于维护模式。

jhuangjiahua

哦~~~~~~~~~~~